Регистрироваться требуют многие. Меня тормознуло другое:
Окей, пересел в рабочий Хром. Жму "создать проект", вижу выбор Size: 1920x1080, 1600x900, 1024x768, 800x600. Без единиц, просто size. Выглядит как растровый размер. Сразу куча вопросов. Как мне быть с 4к-моником? А если у зрителя обычный моник? А если у другого зрителя 4к? А если я про проектор знаю только что он 16:9? В общем, посмотрите на Google Slides (File > Page setup): 4:3, 16:9, 16:10. Ну понятнее же!
Окей, добрался до редактора. В целом опрятно, undo/redo есть. Но вот я хочу переставить слайды:
Чё за фигня?)
Не поймите неправильно. В целом вы делаете хорошо, если на первый взгляд. Но как новый пользователь я очень быстро споткнулся на паре досадных ограничений и багов.
И да, подумайте про регистрацию. Стоит как минимум прикрутить вход через гугл/вк/что-там-ещё. Может, и вовсе вывернуть её наизнанку, чтобы вновь пришедший сразу видел редактор и опционально мог зарегистрироваться.
Это сравнительно безвредный класс аудиофилов. Практически аудиофрики. Вызывают смех даже у тех, кто безошибочно отличает 44,1 кГц / 16 бит от 192 кГц / 24 бит, хотя к последним тоже есть вопросики.
Да вообще ко всем есть вопросики, кто застрял на характеристиках электронной части воспроизводящей аппаратуры. В остальных сферах аудио проблемы дружно игнорируются, обесценивая погоню за циферками.
По мотивам этой заметки сделал проверку commit message на нашем Node.js-проекте. Трекер у нас shortcut.com, поэтому формат айдишников sc-[0-9]+, например sc-12345. Плюс в commit message оно должно быть в квадратных скобках, чтобы shortcut.com этим коммиты прицепил к тикетам. Для автоматической активации хуков используется Husky. Но не суть, всему этому есть аналоги на других стеках. Короче, вот файл .husky/pre-commit
#!/usr/bin/env sh
. "$(dirname -- "$0")/_/husky.sh"
message="$(cat $1)"
if ! [[ $message =~ Merge|\[sc-[0-9]+\] ]];
then
storyId=$(git symbolic-ref --short -q HEAD | grep -Eo 'sc-[0-9]+')
if ! [ -n "$storyId" ]; then
echo "There's no story ID in your commit message, e.g. [sc-10000], nor could we infer it from the branch name. Please add story ID to the message. Alternatively, commit with --no-verify but that's not very cool. Read more on Shortcut+VCS here: https://help.shortcut.com/hc/en-us/articles/115003820646"
exit 1
fi
fi
и вот .husky/prepare-commit-msg
#!/usr/bin/env sh
. "$(dirname -- "$0")/_/husky.sh"
message="$(cat $1)"
if ! [[ $message =~ Merge|\[sc-[0-9]+\] ]];
then
storyId=$(git symbolic-ref --short -q HEAD | grep -Eo 'sc-[0-9]+')
if [ -n "$storyId" ]; then
echo "[$storyId] $message" > $1
fi
fi
Эта связка автоматически добавляет ид тикета, выведенный из названия бранча, в случае когда оной отсутствует. Если ни в commit message, ни в названии бранча ид тикета не обнаруживается, то коммитеру выводится сообщение о том, что он нехороший человек, и как обойти проверку если очень надо. Кроме того, проверка отключена для сообщений, начинающихся на "Merge".
Иногда прокатывает ручная установка драйвера для ближайшей модели.
У меня есть 20-летний Xerox Phaser 3121. Своего драйвера под современную винду на него не сыскать, но она до сих пор комплектуется дровами на Xerox Phaser 3124, которые прекрасно работают с моим 3121.
Да, давайте гнать на ВАЗ, у которого на всех инжекторных машинах с конца 90-х иммобилайзер шёл. Пускай с кучей других уязвимостей, но конкретно ситуация из поста невозможна даже на довольно старых вазиках.
Чтобы долго хранить данные или код, их надо подогревать. Переносить с дискет на жёсткие диски, с дисков - в облака, из облаков - в то, что там дальше придумают. Попутно просматривать, использовать. Код надо постоянно запускать и убеждаться, что он правильно исполняется. Без этого всё канет в Лету неизбежно.
Но и данных на ПК нагенерили гораздо больше, чем на тех мейнфреймах. Даже если отбросить ненужное (а перед этим как-то разделить всё на нужное и ненужное).
Месяц назад диски с фотографиями из нулевых оказались полностью несовместимы с тем, что было у меня дома. Ни одного привода - покупать пришлось. Ещё через 60 лет на эти оптические диски будут смотреть как сегодня на первые HDD из 50-х, которые размером с холодильник. И да, где-то в музее будет стоять этот единственный в стране рабочий ПК.
Справедливо для начала разработки. Но никаких ресурсов не хватит всякий раз решать проблему на корню. Рано или поздно заказчик приходит с очередной идеей, которая не укладывается в ранее заложенные абстракции, а на закладку новых нет времени. И вот тогда вместо специализированного крепежа вы достаёте гвозди / изоленту / клей да идёте обмазывать всё техническим долгом (в том числе имена в коде).
Мы, кажется, о разных вещах говорим. Статья заканчивается скриншотом какой-то консоли с логом:
Там есть текст: Requested weather for city Moscow on 1 day, кототрый берётся из шаблона Requested weather for city {City} on {Day} day. И суть моего комментария в том, что оно того не стоит и даже немного препятствует разбирать логи.
В моём же примере развёрнута строка 79. А там, где "metric", это предыдущая 78. Но не суть. Суть в том, что мы не заморачиваемся с форматированием message как это делается в статье и это, по моему мнению, даже не относится к структурированному логированию. А мы просто гоним структурированный лог JSON'ом в CloudWatch примерно такими вызовами:
this.logger.info('query model updated', { context, aggregateId, aggregateVersion });
И я не вижу смысла пытаться что-то подставлять в 'query model updated'. Оно читаемо для кого надо и в таком виде. То есть на месте автора статьи я бы сделал
_logger.LogInformation("weather requested", city, day, result.First(), @Weather???);
... и этого хватило бы всем, кто смотрит эти логи.
CloudWatch сойдёт за нормальный? Вот на скриншоте статический message. И при этом остальные поля все разложены. Не могу представить зачем бы могло понадобиться запихивать в message что-нибудь из data, типа "query model 3839222b... updated". Как раз я и могу фильтр по-простому задать только благодаря тому, что не меняю message по шаблону.
То есть не всё так просто, как "добавить логирование в middleware всех входящих/исходящих реквестов", да? Про замену юнит-тестов логированием я ничего не говорил.
Я не совсем понимаю зачем в структурных логах что-то шаблонизировать и подставлять. Простые смертные на это не смотрят, а эльфам вполне понятно { "msg": "weather requested", "tempC": 1, "tempF": 33 }, даже меньше места занимает и грепать проще. Ну то есть само сообщение можно оставить статической строкой.
То есть голосовое управление не надо делать, потому что существуют люди с дефектами речи?
Регистрироваться требуют многие. Меня тормознуло другое:
Окей, пересел в рабочий Хром. Жму "создать проект", вижу выбор Size: 1920x1080, 1600x900, 1024x768, 800x600. Без единиц, просто size. Выглядит как растровый размер. Сразу куча вопросов. Как мне быть с 4к-моником? А если у зрителя обычный моник? А если у другого зрителя 4к? А если я про проектор знаю только что он 16:9? В общем, посмотрите на Google Slides (File > Page setup): 4:3, 16:9, 16:10. Ну понятнее же!
Окей, добрался до редактора. В целом опрятно, undo/redo есть. Но вот я хочу переставить слайды:
Чё за фигня?)
Не поймите неправильно. В целом вы делаете хорошо, если на первый взгляд. Но как новый пользователь я очень быстро споткнулся на паре досадных ограничений и багов.
И да, подумайте про регистрацию. Стоит как минимум прикрутить вход через гугл/вк/что-там-ещё. Может, и вовсе вывернуть её наизнанку, чтобы вновь пришедший сразу видел редактор и опционально мог зарегистрироваться.
Это сравнительно безвредный класс аудиофилов. Практически аудиофрики. Вызывают смех даже у тех, кто безошибочно отличает 44,1 кГц / 16 бит от 192 кГц / 24 бит, хотя к последним тоже есть вопросики.
Да вообще ко всем есть вопросики, кто застрял на характеристиках электронной части воспроизводящей аппаратуры. В остальных сферах аудио проблемы дружно игнорируются, обесценивая погоню за циферками.
По мотивам этой заметки сделал проверку commit message на нашем Node.js-проекте. Трекер у нас shortcut.com, поэтому формат айдишников sc-[0-9]+, например sc-12345. Плюс в commit message оно должно быть в квадратных скобках, чтобы shortcut.com этим коммиты прицепил к тикетам. Для автоматической активации хуков используется Husky. Но не суть, всему этому есть аналоги на других стеках. Короче, вот файл
.husky/pre-commitи вот
.husky/prepare-commit-msgЭта связка автоматически добавляет ид тикета, выведенный из названия бранча, в случае когда оной отсутствует. Если ни в commit message, ни в названии бранча ид тикета не обнаруживается, то коммитеру выводится сообщение о том, что он нехороший человек, и как обойти проверку если очень надо. Кроме того, проверка отключена для сообщений, начинающихся на "Merge".
В мире Node.js для этого есть Husky
Иногда прокатывает ручная установка драйвера для ближайшей модели.
У меня есть 20-летний Xerox Phaser 3121. Своего драйвера под современную винду на него не сыскать, но она до сих пор комплектуется дровами на Xerox Phaser 3124, которые прекрасно работают с моим 3121.
Платная альтернатива бесплатным лицензиям?) Не, я всё понимаю про сложность оплаты слака и тимс, но всё равно заголовок странный выходит.
Всё сложнее: https://source.android.com/docs/core/audio/latency/app
Какова задержка от микрофона одного телефона до динамика другого?
Я не уверен, что с этим надо бороться в рамках уголовного кодекса.
Да, давайте гнать на ВАЗ, у которого на всех инжекторных машинах с конца 90-х иммобилайзер шёл. Пускай с кучей других уязвимостей, но конкретно ситуация из поста невозможна даже на довольно старых вазиках.
Тут надо уточнить, что в наличии они были лет 15 назад в лучшем случае. Модель 2003 года. Сейчас подобные стоят около 70.
Чтобы долго хранить данные или код, их надо подогревать. Переносить с дискет на жёсткие диски, с дисков - в облака, из облаков - в то, что там дальше придумают. Попутно просматривать, использовать. Код надо постоянно запускать и убеждаться, что он правильно исполняется. Без этого всё канет в Лету неизбежно.
Но и данных на ПК нагенерили гораздо больше, чем на тех мейнфреймах. Даже если отбросить ненужное (а перед этим как-то разделить всё на нужное и ненужное).
Месяц назад диски с фотографиями из нулевых оказались полностью несовместимы с тем, что было у меня дома. Ни одного привода - покупать пришлось. Ещё через 60 лет на эти оптические диски будут смотреть как сегодня на первые HDD из 50-х, которые размером с холодильник. И да, где-то в музее будет стоять этот единственный в стране рабочий ПК.
Справедливо для начала разработки. Но никаких ресурсов не хватит всякий раз решать проблему на корню. Рано или поздно заказчик приходит с очередной идеей, которая не укладывается в ранее заложенные абстракции, а на закладку новых нет времени. И вот тогда вместо специализированного крепежа вы достаёте гвозди / изоленту / клей да идёте обмазывать всё техническим долгом (в том числе имена в коде).
Мы, кажется, о разных вещах говорим. Статья заканчивается скриншотом какой-то консоли с логом:
Там есть текст:
Requested weather for city Moscow on 1 day, кототрый берётся из шаблонаRequested weather for city {City} on {Day} day. И суть моего комментария в том, что оно того не стоит и даже немного препятствует разбирать логи.В моём же примере развёрнута строка 79. А там, где "metric", это предыдущая 78. Но не суть. Суть в том, что мы не заморачиваемся с форматированием message как это делается в статье и это, по моему мнению, даже не относится к структурированному логированию. А мы просто гоним структурированный лог JSON'ом в CloudWatch примерно такими вызовами:
И я не вижу смысла пытаться что-то подставлять в 'query model updated'. Оно читаемо для кого надо и в таком виде. То есть на месте автора статьи я бы сделал
... и этого хватило бы всем, кто смотрит эти логи.
CloudWatch сойдёт за нормальный? Вот на скриншоте статический
message. И при этом остальные поля все разложены. Не могу представить зачем бы могло понадобиться запихивать вmessageчто-нибудь изdata, типа "query model 3839222b... updated". Как раз я и могу фильтр по-простому задать только благодаря тому, что не меняюmessageпо шаблону.То есть не всё так просто, как "добавить логирование в middleware всех входящих/исходящих реквестов", да? Про замену юнит-тестов логированием я ничего не говорил.
Я не совсем понимаю зачем в структурных логах что-то шаблонизировать и подставлять. Простые смертные на это не смотрят, а эльфам вполне понятно
{ "msg": "weather requested", "tempC": 1, "tempF": 33 }, даже меньше места занимает и грепать проще. Ну то есть само сообщение можно оставить статической строкой.... вместе с паролями, токенами и файлами на пару гигабайт.
... и кусать локти пытаясь диагностировать любые непредвиденные кейсы.
Aspect-oriented programming вам в помощь, но только не в виде мидлвари на самом входе и на самом выходе.