Я не сисадмин, в линуксах ориентируюсь постольку поскольку, так что история носит название "я у мамки хацкер". У меня на ноутбуке дуал бутом стояли Win10 и Kubuntu 18.04. Так получилось, что всё последнее время я работал из-под Win10. Где-то в середине прошлого года приспичило поработать на Linux и я подумал — это же отличная возможность проапдейтиться до 20.04! Так и сделал, всё заработало, всё понравилось.
При следующем включении — чёрный экран при попытке залогиниться. Ну, проблема же известная, наверняка драйвера NVidia. Пробуем всяческие nomodeset — нифига, всё так же зависает на чёрном экране. Другие советы из интернета и переустановка/замена драйверов на nouveau так же не помогли. Ладно, наверное что-то неправильно накатилось; /home на отдельном разделе, там же полно всяких данных и скриптиков, систему можно переустановить с нуля. Переустанавливаем — при первом запуске всё работает, перезагружаем — снова чёрный экран.
Следующая мысль: может проблема с какими-то драйверами от ноута? Смотрим syslog и прочие log — с виду всё чисто, никто не жалуется. Система просто останавливается в какой-то момент. Попробуем откатить обратно на 18.04. Переустанавливаем — работает, перезагружаем — работает! sudo apt-get upgrade, перезагружаем — чёрный экран!!! Вашу ж мать!
Следующая мысль: при переустановке я не перезатирал /home и указывал существующего пользователя при установке системы, соответственно все старые конфиги сохранялись, может где-то несовместимость конфигов? Счётчик переустановок +1, снова 20.04, но на этот раз создаём нового пользователя. Первый запуск — работает, перезагрузка — работает, sudo apt-get upgrade — работает!!! Отлично, можно жить, подумал я. Сделал наконец исходную задачу, начал обживаться, восстанавливать потихоньку программы, конфиги. Периодически перезагружал и в какой-то момент оно снова перестало работать.
Итак, проблема почти локализована, понятно, что дело в конфигах, но систему на всякий случай переставил ещё раз. Восстанавливаю всё с нуля, перезагружаюсь после практически каждого шага, после накатывания новой пачки файлов снова чёрный экран. Заходим в консоль и начинаем удалять по одному файлу из пачки, перезагружаясь после каждого файла… барабанная дробь… наш победитель предатель — .bashrc!!! Стоило его (слегка модифицированный, с какими-то алиасами и переменными) удалить, как сразу проблема ушла. Не стал до конца докапывать, что именно ломалось и из-за какой переменной/алиаса/чего ещё, потому что на тот момент был слишком травмирован такой нелепостью, а потом стало лень.
Меня вопрос интересует ещё с тех пор как занимался ROS2, там middleware — это тоже промежуточный слой, в качестве которого выступает одна из реализаций DDS. На тот момент мне показался адекватным перевод этого слова как "посредник", ибо middleware выполняло роль "доставщика" сообщений.
В отчётах "промежуточное/связующее ПО" смотрится нормально, но для повседневной речи термины слишком громоздкие, а "мидлвар(я)" у нас тогда как-то не прижилось; неудобно произносить по сравнению, скажем, с "софтваром", которого можно сократить до "софт" и всем будет понятно.
Ход конём — раз они всё равно украдены и станут доступны общественности, CDProject может выложить исходники в опен сорс (под какой-нибудь ограничивающей лицензией), чтобы баги искали всем миром!
Но, в отличие от художника, программисты не могут «отойти на шаг назад».
По моему убеждению, такими "мазками" для программиста являются абстракции (которые могут включать другие абстракции, которые...). Ковыряние с неудачными абстракциями подобно тому, что художнику придётся просчитывать количество наносимой краски вплоть до молекул, чтобы холст не сгорел как только на него кто-нибудь посмотрит. И наоборот, если подобраны удачно, программист может добавить десяток таких "мазков" и получить из них библиотеку "голова" — вполне можно будет отойти назад и посмотреть, какая красивая получилась "голова" и как хорошо она соединяется с экзешником "туловище" через RPC-мостик "шея".
Может быть мне так везло, но рекомендации Я.Музыки совершенно ужасны. Хуже только у ВК/Boom. Они совершенно не способствуют рекламе малоизвестных исполнителей, потому что продвигают в основном уже популярных. Spotify в этом плане лучше, но опять-таки, там присутствуют уже устоявшиеся музыканты, и что-то по-настоящему новое там найти сложно, тогда как на Bandcamp есть совершенно уникальные альбомы.
Ждём сервис, который объединит Spotify и Bandcamp.
Я честно говоря думал, что чтобы исключить влияние сейсмической активности через любые конструкции. Я не помню, где в сериале дело происходит, но если в районе Калифорнии, то там по идее оно случается достаточно часто. А семь метров — чтобы увеличить объём вакуумной области — чем она будет больше, тем медленнее будет заполняться при утечке.
В шарпе модификатор internal, да, это то самое. Публично, но только в рамках отдельной условной единицы (сборки, группы пользователей...).
Что-то не так с чатами
Нет, их ровно столько сколько нужно. Основные потребности в пересылке — это когда
1) багу/пожелание из чатов продажников пересылают разрабам
2) когда бага фронтенда оказывается багой бека
3) когда сообщение из локального группового чата пересылаешь одному из его же участников — напомнить, задать вопрос и т.д. Можно конечно в том же чате отписаться, но почему нельзя (по крайней мере было) отдельному участнику отправить — не очень понятно
У нас сейчас например в слаке почти все каналы для разработчиков приватные, потому что в этом же слаке обитают продажники с полными правами (раньше когда они были "multi-channel guests", такой проблемы не стояло), которым видеть внутренние тёрки не надо. И из одного внутреннего чата в другой взять и "расшарить" невозможно, что некритично (справляемся копированием-вставкой ссылок на сообщения), но не неудобно.
Возможно, это решается настройкой каналов, публичных только для отдельных групп пользователей (или нельзя, не знаю), но у нас никто не заморачивается.
Мне очень понравилось для заметок использовать пространство Slack, где я единственный пользователь. Удобные приложение под все платформы, встроенный синк между всеми платформами, хранит драфты сообщений, легко отредактировать уже отправленные. На каждую тему по каналу, можно подискутировать с самим собой в тредах. Есть миллионы интеграций со сторонними приложениями.
Из минусов — плохо работает в оффлайне, неудобный поиск, невозможность прикрутить теги к сообщениям (каналы отчасти выполняют роль тегов, но "добавить несолько тегов" превращается в "отправлять в несколько каналов" — что жутко неудобно). Для выписывания разовых мыслей и заметок (когда точно знаешь, что вряд ли это будешь перечитывать в далёком будущем) — самое то.
Qt достаточно широко распространён, чтобы статические анализаторы искали специфичные для фреймворка вещи. Тот же Resharper, например, выдаёт специфичные для Unity проектов предупреждения.
Это тоже вариант, но не люблю заморачиваться с приведениями типов. Плюс, опять же, "внешнему" пользователю не нужен второй тип (тот, что используется внутри PointConvert(который во втором комментарии случайно превратился в TransformPoint, ну да ладно)), он использует только первый.
Так что смысл был как раз запретить передавать второй тип там, где правильно передавать первый; вопрос превращается в — как разрулить различие внешнего и внутреннего API при прочих плюсах декоратора. Наверное, стоило декоратор как-то повнятнее назвать, вроде @convert_vector_to_bcf, потому что @bcf можно и не заметить. Но честно говоря, больше в голову ничего не приходит.
Сигнатура отличается, да, надо помнить, что в данном случае декоратор её изменяет. Но если воспринимать этот класс как "библиотечку", то её пользователю всё равно как оно там, главное что на вход он может передавать ровно то, что хотел. Автодополнение (по крайней мере в VSCode) отрабатывает правильно, с учётом декоратора:
(method) PointConvert: (p1: Vector) -> Vector
Можно было бы:
Обойтись без декоратора, внедрять From/To в каждый из методов. Их там штук пять, не так уж сложно, но внешне загромождает вид. И если вдруг формат входящих значения опять поменяют, менять придётся везде.
Обойтись без изменения сигнатуры и не вводить второй класс BCFVector, но тогда мы рискуем рано или поздно передать в функцию вектор не в той системе координат и получить трудноотлавливаемую багу.
Обойтись без декоратора, использовать враппер в явном виде:
И такая однотипная ерунда для каждой функции, что просто захламляет файлик. Ещё у пользователя "библиотечки" будет болтаться второй комплект методов в автодополнении, хоть мы и сделали их "приватными".
В общем, мне показалось использование такого декоратора оптимальным выходом с наименьшей писаниной. Ещё бы засунуть его внутрь класса, в котором он используется (сейчас он висит отдельной функцией), чтобы упростить передачу UnitTransform через self, но у меня с наскока чё-то не получилось.(
Ну вот буквально на днях запилил скриптик, который должен был применять некоторые преобразования к вектору. Однако обнаружилось, что векторы, которые поступают на вход, немного не в том формате, в котором ожидалось. Пилим два классика: Vector (который приходит) и BCFVector (который отличается только системой координат, нужен, чтобы mypy не давал передавать один тип там, где ожидается другой) и к ним две функции ToBCF и FromBCF.
def bcf(
fn: Callable[[UnitTransform, BCFVector], BCFVector]
) -> Callable[[UnitTransform, Vector], Vector]:
"""Make automatic convert to and from BCF."""
def wrapper(ut: UnitTransform, vector: Vector) -> Vector:
return FromBCF(fn(ut, ToBCF(vector)))
return wrapper
class UnitTransform:
@bcf
def PointConvert(self, point: BCFVector) -> BCFVector:
...
src = Vector(0, 1, 2) # не BCFVector!
res = transform.PointConvert(src)
Везде удобно и при этом не надо переживать, что где-то накосячил с преобразованием из одного формата в другой.
Диверсифицировать по жанрам — нормально, когда есть нормальная система жанров, а не какой-нибудь "иностранный рок", в который смешивают всё. В этом плане лучше всего показывает себя Bandcamp, там теги достаточно разнообразные, и музыканты могут сами проидентифицировать собственную музыку; подписываясь на "black metal" или "post-punk" я с большой вероятностью услышу именно то что ожидаю.
Баянклассика:https://xakep.ru/2006/12/16/35784/
Я не сисадмин, в линуксах ориентируюсь постольку поскольку, так что история носит название "я у мамки хацкер". У меня на ноутбуке дуал бутом стояли Win10 и Kubuntu 18.04. Так получилось, что всё последнее время я работал из-под Win10. Где-то в середине прошлого года приспичило поработать на Linux и я подумал — это же отличная возможность проапдейтиться до 20.04! Так и сделал, всё заработало, всё понравилось.
При следующем включении — чёрный экран при попытке залогиниться. Ну, проблема же известная, наверняка драйвера NVidia. Пробуем всяческие
nomodeset— нифига, всё так же зависает на чёрном экране. Другие советы из интернета и переустановка/замена драйверов наnouveauтак же не помогли. Ладно, наверное что-то неправильно накатилось;/homeна отдельном разделе, там же полно всяких данных и скриптиков, систему можно переустановить с нуля. Переустанавливаем — при первом запуске всё работает, перезагружаем — снова чёрный экран.Следующая мысль: может проблема с какими-то драйверами от ноута? Смотрим syslog и прочие log — с виду всё чисто, никто не жалуется. Система просто останавливается в какой-то момент. Попробуем откатить обратно на 18.04. Переустанавливаем — работает, перезагружаем — работает!
sudo apt-get upgrade, перезагружаем — чёрный экран!!! Вашу ж мать!Следующая мысль: при переустановке я не перезатирал
/homeи указывал существующего пользователя при установке системы, соответственно все старые конфиги сохранялись, может где-то несовместимость конфигов? Счётчик переустановок +1, снова 20.04, но на этот раз создаём нового пользователя. Первый запуск — работает, перезагрузка — работает,sudo apt-get upgrade— работает!!! Отлично, можно жить, подумал я. Сделал наконец исходную задачу, начал обживаться, восстанавливать потихоньку программы, конфиги. Периодически перезагружал и в какой-то момент оно снова перестало работать.Итак, проблема почти локализована, понятно, что дело в конфигах, но систему на всякий случай переставил ещё раз. Восстанавливаю всё с нуля, перезагружаюсь после практически каждого шага, после накатывания новой пачки файлов снова чёрный экран. Заходим в консоль и начинаем удалять по одному файлу из пачки, перезагружаясь после каждого файла… барабанная дробь… наш
победительпредатель —.bashrc!!! Стоило его (слегка модифицированный, с какими-то алиасами и переменными) удалить, как сразу проблема ушла. Не стал до конца докапывать, что именно ломалось и из-за какой переменной/алиаса/чего ещё, потому что на тот момент был слишком травмирован такой нелепостью, а потом стало лень.Меня вопрос интересует ещё с тех пор как занимался ROS2, там middleware — это тоже промежуточный слой, в качестве которого выступает одна из реализаций DDS. На тот момент мне показался адекватным перевод этого слова как "посредник", ибо middleware выполняло роль "доставщика" сообщений.
В отчётах "промежуточное/связующее ПО" смотрится нормально, но для повседневной речи термины слишком громоздкие, а "мидлвар(я)" у нас тогда как-то не прижилось; неудобно произносить по сравнению, скажем, с "софтваром", которого можно сократить до "софт" и всем будет понятно.
Без сарказмов, любопытства ради. Существует ли устоявшееся хоть где-нибудь написание слова middleware в кириллице? Связующее ПО не предлагать.
Ход конём — раз они всё равно украдены и станут доступны общественности, CDProject может выложить исходники в опен сорс (под какой-нибудь ограничивающей лицензией), чтобы баги искали всем миром!
del
По моему убеждению, такими "мазками" для программиста являются абстракции (которые могут включать другие абстракции, которые...). Ковыряние с неудачными абстракциями подобно тому, что художнику придётся просчитывать количество наносимой краски вплоть до молекул, чтобы холст не сгорел как только на него кто-нибудь посмотрит. И наоборот, если подобраны удачно, программист может добавить десяток таких "мазков" и получить из них библиотеку "голова" — вполне можно будет отойти назад и посмотреть, какая красивая получилась "голова" и как хорошо она соединяется с экзешником "туловище" через RPC-мостик "шея".
Может быть мне так везло, но рекомендации Я.Музыки совершенно ужасны. Хуже только у ВК/Boom. Они совершенно не способствуют рекламе малоизвестных исполнителей, потому что продвигают в основном уже популярных. Spotify в этом плане лучше, но опять-таки, там присутствуют уже устоявшиеся музыканты, и что-то по-настоящему новое там найти сложно, тогда как на Bandcamp есть совершенно уникальные альбомы.
Ждём сервис, который объединит Spotify и Bandcamp.
Я честно говоря думал, что чтобы исключить влияние сейсмической активности через любые конструкции. Я не помню, где в сериале дело происходит, но если в районе Калифорнии, то там по идее оно случается достаточно часто. А семь метров — чтобы увеличить объём вакуумной области — чем она будет больше, тем медленнее будет заполняться при утечке.
Мне аж интересно стало, я затестил.
2 * (дабл-клик +
Ctrl-C+Ctrl-V) ~ 5 секундВ шарпе модификатор
internal, да, это то самое. Публично, но только в рамках отдельной условной единицы (сборки, группы пользователей...).Нет, их ровно столько сколько нужно. Основные потребности в пересылке — это когда
1) багу/пожелание из чатов продажников пересылают разрабам
2) когда бага фронтенда оказывается багой бека
3) когда сообщение из локального группового чата пересылаешь одному из его же участников — напомнить, задать вопрос и т.д. Можно конечно в том же чате отписаться, но почему нельзя (по крайней мере было) отдельному участнику отправить — не очень понятно
У нас сейчас например в слаке почти все каналы для разработчиков приватные, потому что в этом же слаке обитают продажники с полными правами (раньше когда они были "multi-channel guests", такой проблемы не стояло), которым видеть внутренние тёрки не надо. И из одного внутреннего чата в другой взять и "расшарить" невозможно, что некритично (справляемся копированием-вставкой ссылок на сообщения), но не неудобно.
Возможно, это решается настройкой каналов, публичных только для отдельных групп пользователей (или нельзя, не знаю), но у нас никто не заморачивается.
Почему именно русский перевод? Русский язык в интерфейс, например, до сих пор не завезли.
Мне очень понравилось для заметок использовать пространство Slack, где я единственный пользователь. Удобные приложение под все платформы, встроенный синк между всеми платформами, хранит драфты сообщений, легко отредактировать уже отправленные. На каждую тему по каналу, можно подискутировать с самим собой в тредах. Есть миллионы интеграций со сторонними приложениями.
Из минусов — плохо работает в оффлайне, неудобный поиск, невозможность прикрутить теги к сообщениям (каналы отчасти выполняют роль тегов, но "добавить несолько тегов" превращается в "отправлять в несколько каналов" — что жутко неудобно). Для выписывания разовых мыслей и заметок (когда точно знаешь, что вряд ли это будешь перечитывать в далёком будущем) — самое то.
Qt достаточно широко распространён, чтобы статические анализаторы искали специфичные для фреймворка вещи. Тот же Resharper, например, выдаёт специфичные для Unity проектов предупреждения.
Это тоже вариант, но не люблю заморачиваться с приведениями типов. Плюс, опять же, "внешнему" пользователю не нужен второй тип (тот, что используется внутри
PointConvert(который во втором комментарии случайно превратился вTransformPoint, ну да ладно)), он использует только первый.Так что смысл был как раз запретить передавать второй тип там, где правильно передавать первый; вопрос превращается в — как разрулить различие внешнего и внутреннего API при прочих плюсах декоратора. Наверное, стоило декоратор как-то повнятнее назвать, вроде
@convert_vector_to_bcf, потому что@bcfможно и не заметить. Но честно говоря, больше в голову ничего не приходит.Сигнатура отличается, да, надо помнить, что в данном случае декоратор её изменяет. Но если воспринимать этот класс как "библиотечку", то её пользователю всё равно как оно там, главное что на вход он может передавать ровно то, что хотел. Автодополнение (по крайней мере в VSCode) отрабатывает правильно, с учётом декоратора:
Можно было бы:
BCFVector, но тогда мы рискуем рано или поздно передать в функцию вектор не в той системе координат и получить трудноотлавливаемую багу.И такая однотипная ерунда для каждой функции, что просто захламляет файлик. Ещё у пользователя "библиотечки" будет болтаться второй комплект методов в автодополнении, хоть мы и сделали их "приватными".
В общем, мне показалось использование такого декоратора оптимальным выходом с наименьшей писаниной. Ещё бы засунуть его внутрь класса, в котором он используется (сейчас он висит отдельной функцией), чтобы упростить передачу
UnitTransformчерезself, но у меня с наскока чё-то не получилось.(Ну вот буквально на днях запилил скриптик, который должен был применять некоторые преобразования к вектору. Однако обнаружилось, что векторы, которые поступают на вход, немного не в том формате, в котором ожидалось. Пилим два классика:
Vector(который приходит) иBCFVector(который отличается только системой координат, нужен, чтобыmypyне давал передавать один тип там, где ожидается другой) и к ним две функцииToBCFиFromBCF.Везде удобно и при этом не надо переживать, что где-то накосячил с преобразованием из одного формата в другой.
В таком случае эффективнее сортировка Таноса: если массив не отсортирован, удаляем половину.
Диверсифицировать по жанрам — нормально, когда есть нормальная система жанров, а не какой-нибудь "иностранный рок", в который смешивают всё. В этом плане лучше всего показывает себя Bandcamp, там теги достаточно разнообразные, и музыканты могут сами проидентифицировать собственную музыку; подписываясь на "black metal" или "post-punk" я с большой вероятностью услышу именно то что ожидаю.