Я не синьор (да и вообще не программист официально), но для меня лично переломным стало понимание того, что нужно прочитать и осознать что тебе пишет компилятор/интерпретатор (а если есть возможность - то вообще линтер). Причем сделать это перед тем, как гуглить. Возможно и гуглить не нужно будет, и в голове больше отложится.
Ну в таком случае давайте разделять "привычнее" и "удобнее" :)
ssh-config будет работать в cmd/powershell/WindowsTerminal с маленьким хаком будет автоматически загребать изменения и работать в любом запущенном инстансе wsl. Будет работать для ssh/scp/sftp/sshfs. Будет работать если вы пришли на домашнюю машину через ssh с любого другого места, вплоть до подключения домой с телефона (я пользуюсь JuiceSSH). А скопировав с помощью scp его на другой линуксовый хост - он будет работать и на том хосте.
Из обязательного, что нашел через промежуток времени после написания комментария: нужно проверять на наличие файла перед ffmpeg. Если файла нет - выходить с указанием, что файл не найден.
Из необязательного, но было бы правильно: после ffmpeg'а и обрезания вывода проверить переменную dur на соответствие регулярному выражению.
Из вообще мелочей: их много, но больше всего меня беспокоит две. 1) заменить '%H:%M:%S' на '%T'; 2) Всё таки попробовать заменить все bc на $(()), если получится (лень проверять сейчас). Первое визуально сократит код, второе может сделать его быстрее, потому что вызов отдельного приложения - всегда накладные расходы и время. Одна только замена в вызове date после собаки на $(($step * 15)) - уже дает почти двухкратное увеличение скорости выполнения на небольшом файле (длительность 3:23):
# before:
# timing=$(TZ=GMT date -d @$(bc <<< "$step * 15") +'%H:%M:%S')
bash script2.sh fl.mp3 0.08s user 0.38s system 20% cpu 2.170 total
# after:
# timing=$(TZ=GMT date -d @$(($step * 15)) +'%T')
bash script2.sh fl.mp3 0.05s user 0.19s system 19% cpu 1.200 total
# Для сравнения - скрипт из поста:
bash script.sh fl.mp3 2.09s user 0.66s system 43% cpu 6.295 total
Кстати, пока писал коммент - обнаружил, что скрипт автора выводит время сверху длительности файла. Т.е. мой файл 3:23, скрипт автора последним таймингом выводит 3:30. Я что бы этому соответствовать - добавил в вычисление steps +1. Его нужно убрать, потому что это, имхо, неверно.
Я лишь пытался намекнуть, что многое можно сделать проще, а многое лучше. Я тоже не программист. Мне понадобилось определенное время, что бы написать тот код, который я приведу ниже. Сделал это исключительно ради освежения своих знаний.
Сделал нарочито просто, без сокращений. Уверен, что можно написать красивее (но понимать "непрограммисту" будет сложнее). Знаю, что можно написать короче. Подозреваю, что мой код тоже не идеален, и его улучшать и улучшать.
Первый блок кода это usage - он не нужен для работы скрипта, но сильно помогает когда им делишься. Потом с помощью ffmpeg (который вы использовали) мы получаем длительность. Не понятно, зачем вы в вашем решении били на отрезки, зачем потом проверяли наличие отрезков. Это всё вычислительные ресурсы, которые не нужны. Дальше используя количество шагов мы просто выводим тайминги с нужным вам форматом. Всё. Если нужно решить конкретно вашу задачу - то даже такое решение уже сильно проще. Имхо, читаемее.
Попробуйте воспринимать это не через призму критики ради вашего оскорбления, а с призмы попытки подсказать вам, что можно сделать лучше в будущем. У меня не было цели вас задеть.
ssh клиент в винде уже научился понимать ssh-config (~/.ssh/config). Там намного удобнее прописать конкретные настройки хоста и туннелирование. Бонусом: эти конфиги будут прекрасно работать на любом линуксе с openssh
Зашел попробовать, первую партию слил очень быстро. Начал искать варианты, но со второй партии стал ощущать, что бот, похоже, видит всю доску. Слишком "дерзкие" атаки. Еще очень сильно сбивает, когда "туман войны" появляется в твоих рядах. Головой я помню расположение, и знаю, что там ничего нет (во всяком случае в начале игры). Но очень сильно сбивает. В общем после еще ряда попыток устал, пошел дочитывать комментарий, и аж отлегло. Бот таки видит всю доску, и это многое объясняет. Много думал над разработкой бота для старкрфта, так вот там если самому простому боту включить "мапхак" - то он с легкостью выносит противников, которые гораздо сильнее его (впрочем, с людьми это работает ровно так же).
Рискую быть обвинен в занудстве, но есть несколько вопросов/предложений:
>Обычно работа по транскрибации оплачивается по времени записи. Было бы удобно сразу после завершения работы видеть и сумму, которую вам должен будет заплатить заказчик. >Скрипт определяет стоимость работы исходя из расценки 17 р/мин. Эта цена настраивается в строке 65 указанием цены за 15 секунд.
Почему бы сразу не взять длительность файла в минутах (с округлением вверх) и не умножить ее на 17? Весь блок кода будет заменен одной строкой, не будет дробных чисел, и в целом всё будет сильно читабельнее.
>Имя аудио файла не должно содержать пробелов и лишних точек
Так же как и с выходящим файлом - лучше просто разобраться как работать с файлами, содержащими пробелы и другие символы. Было бы и более "юзерфрендли" и больше "защиты от дурака".
Я попробовал запустить скрипт, и получил чистый экран терминала. Предварительно вывалилась какая-то ошибка (ffmpeg вроде). И ничего больше. В целом-то понятно, что ему нужно передать какой-то аргумент, но сам скрипт ничего не ответил на эту тему. Хорошей практикой будет сделать проверку на наличие аргумента, и в случае его отсутствия выдать usage. Вы же сами, если какое-то время не будете пользоваться своей наработкой - забудете/запутаетесь. Придется открывать код и вспоминать. Так вы еще и презентуете это, а раз так - то неплохо бы сделать хорошо :)
В принципе очень много беспорядка в коде. Лишние комментарии, лишние пробелы, отступы, неочевидные конструкции, общая "неоднородность" кода. Например, что делает команда эта команда?
А точнее ее первая часть. Зачем она тут нужна? Зачем столько лишних символов во второй части? cat text_1.txt >> $BNAME.txt сработает так же. А cat file >> "${BNAME}.txt" еще и без проблем сработает при файле с пробелом.
Почему в каких-то случаях использована конструкция $(command) а в каких-то `command`? Рекомендации к использованию парных скобок $() давно описаны, их легче дебажить, чем непарные ``. Почему переменные стилистически используются по-разному? Когда ${var}, когда $var. Есть понимание, или это "от балды"? Зачем конструкции типа F_NAME_FULL="./"$BNAME"."$EXT, если ее заменит F_NAME_FULL=$BNAME.$EXT? Если хочется извращаться с точка-слеш перед названием файла (хотя нужно понять зачем это делать) - то хватит "./${BNAME}.${EXT}". Возможно ли все "математические" операции привести к одному виду, что бы использовать что-то одно из expr, bc, $(())? Конструкция (echo "X")>>./text_1.txt вообще феерична :) Зачем грузить во временные файлы всё, если можно грузить в память? В случае если скрипт сломается посредине (или будет остановлен) - хотя бы не останется кучки мусора. В конце концов зачем clear в конце? Может я логи почитать хочу :) без tmux'а я бы этого сделать не смог.
Мне кажется, что если навести порядок в коде - статья уже будет иметь большую ценность, хотя бы с точки зрения самообразования автора.
В заключение: при всей моей любви к башу в целом, при тысячах строк написанных мною в собственных баш-портянках - сегодня подобное я бы стал делать только если хочется потренировать непосредственно баш. Если бы мне нужно было решать задачу - я бы, вероятнее, взял пайтон, начал с малого, но двигался бы в сторону автоматического определения наличия разговора в определенном временном диапазоне, динамическое создание таких временных диапазонов, и, возможно, автоматический перевод аудио в текст. После чего просто подредактировать тайминги там, где это нужно и отдать корректору (или самому) на корректирование ошибок автоматического преобразования. А может быть в сторону интерактивности, где после определения временного диапазона этот диапазон проигрывается в цикле, а в окошке есть возможность сразу редактировать временной интервал и "распознанный" текст. На сегодняшний день это звучит вполне реальной задачей.
Есть микрофоны с аппаратным отключением звука. Есть внешние звуковые карты (у меня стоит 2i2, я вполне доволен, но это решение для стационарных ПК)
Ещё можно выключать на уровне ОС. Под линуксом, думаю, объяснять не нужно. Под виндой я написал себе маленький скрипт на AHK, собрал в бинарь и использую его что бы сделать мьют микрофона на уровне ОС. Да, это не 100% гарантия, что микрофон не сможет использовать телеметрия майкрософтов, но с таким подходом ни гугл-митс ни зум ни цискомит до звука не добираются. Гугл видит что микрофон в мьюте и регулярно на это ругается)) А вообще такое решение имеет дополнительный плюс: один хоткей на выключение микрофона во всех приложениях, и работает он в любом окне системы (думаю всем знакома ситуация, когда у тебя что-то спрашивают, а ты в другом окне и судорожно начинаешь искать вкладку в хроме, в которой мит)
Подозреваю, вы делали покупки под какие-то распродажи типо 11-11. Многие банки под такие события выключают проверку лимитов и отменяют 3дс до определенных сумм (20-50$ на одну операцию). Мотивируют это удобством клиента. На самом деле разгружают поток обращений в коллцентре. Малый процент недовольных слихвой покрывается большим количеством транзакций, с которых банк заработает. Единицы дойдущие до суда - скорее всего проиграют. Кому-то, возможно, вернут. Но для банка это копейки. А заработал он много.
Вы либо читаете через строку, либо занимаетесь перекручиванием. Потому что в моем комментарии таких посылов нет, особенно про наказание.
Идеальный вариант для меня - развитие общественного транспорта и велоинфраструктуры. И значительное уменьшение доли персонального транспорта на дорогах. Снижение максимальной разрешенной скорости в городе. Реально большие штрафы за нарушения. Неизбежность наказания за нарушения. Вот это - идеальный вариант для меня.
А по поводу "таких городов не существует" - есть города, которые к этому стремятся. И качество жизни в таких городах сильно выше дефолт-сити и городов тех стран, которые идут по ошибочному пути строительства дорог ради решения проблем пробок (что, ожидаемо, приводит только к увеличению пробок). Вы можете не доверять мне и моим словам, это нормально. Но для вас тысячи статей по урбанистике написаны. С исследованиями и доказательствами. Почитайте про концепцию Vision Zero. Почитайте другие материалы по урбанистике, хотя бы для общего развития. И вы увидите логику повествования и проблемное направление текущего развития городов постсоветского пространства. Да, господи, даже автор поста достаточно сумбурно накопипастил фраз из источников, которые он указал внизу статьи.
PS. Наперед отвечая на вопросы, которые неизбежно появляются в рамках любой похожей дискуссии: у меня есть автомобиль. Хороший. В семье даже не один. Да, я езжу на нем (примерно тысяч по 30 в год, что выше среднего показателя). Но при этом я всё равно за "ущемление" автомобилистов ради пешеходов/велосипедистов/общественного транспорта. Ибо именно это, как правило, приводит к решению вопроса пробок.
Штрафы копеечные. Штраф за угрозу жизни окружающим (читай стрельба в общественном месте) после 50% скидки сколько? 10-12 баксов? Да частью людей это воспринимается не как штрафы, а как плату за нарушение. Такая себе выделенная платная дорога. Только не выделенная. Штрафы за парковку значительные только если эвакуатор забрал. Гайки не то, что затянуты - они разболтаны и вот-вот сорвутся.
> Поэтому все эти вопросы штрафов, наказаний и т.д. - это вопрос балансов. И если в какой-то момент резьба становится перезатянутой, она ломается.
Мне кажется, что эта мысль близка к правильной. Но либо я пропустил абзац, либо предложения сделать штрафы слишком большими - не было. При этом, мы видим страны, которые пользуются знаниями и выводами такой сферы, как урбанистика. Более того, мы любим отдыхать именно в таких странах. Нам классно, когда машин и дорог меньше, вело/пешеходных и зеленых зон - больше.
Живем-то мы тут. И пока мы опустив руки будем говорить "живем-то мы тут, ничего не изменить" - ничего и не поменяется. Более того, у нас есть примеры и опыт тех стран, которые на правильном пути. Страны, в которых закон более работоспособен. Можно было бы учиться на чужих ошибках, но мы так не умеем.
К сожалению, автор поста по непонятной причине спорит со всеми, не придавая значения тому, что он попытался сложные вещи описать простым языком, получилось всё равно сложно, еще более запутано и местами весьма криво :)
Итогом получаем неплохую, но бесполезную тему для обсуждения в таком ключе. Новичку в музыке я бы не рекомендовал читать это, только запутает
В подтверждение ваших слов: тут есть влияние опыта. Запись музыки нотами примерно аналогична записи слов буквами. Опытный читатель вполне осилит проговорить у себя в голове то, что написано буквами. И наоборот, мы думаем не проговаривая слова, и сразу печатаем их в текст. Так и опытный композитор в голове проигрывает мелодию, и если она ему нравится - переписывает на бумагу. Технически - сразу нотами на бумагу. Фактически - до этого происходит мозговая активность что бы понять, что именно написать.
У ИТ отдела как правило не один заказчик. Но другие ведь справляются :)
Что бы понять чьи хотелки делать раньше - нужен некий скоринг заявок. Лучше, если этот скоринг будет делать бизнес. Если есть единый руководитель бизнеса - то в итоге он. Если нет - то пусть руководители бизнесов собираются и обсуждают друг с другом кто важнее.
А вот занятость разработчиков не волнует тех, кто сверху, пока руководитель разработчиков не может правильно донести до верхов текущую ситуацию.
Ну у вас ведь есть система ведения отчетности о проделанной работе? Система трекинга времени? Если новые вещи не имплементируются или задачи выполняются долго - то нужно показать почему. Если отдел из N разработчиков тратит время на поддержку старых продуктов - то, к сожалению для них [разработчиков этого отдела], они должны доносить об этом руководству/заказчику. И либо нанимайте доп.персонал, либо откладываем реализацию новых фич и занимаемся рефакторингом старых проектов. Как правило, после рефакторинга оказывается, что как минимум третью уже никто не пользуется, еще третью пользуются единицы, а еще треть - это дублирующий функционал. Можно напрячься, сделать самим, нарисовать красивую презентацию о проделанной работе и прийти к руководству с запросом на повышение. В зависимости от развития событий - принимать соответствующие решения.
На моем опыте чаще компании (или руководители подразделений в больших компаниях) даже не знают о такой возможности. А потом "а что, так можно было?". И тут несколько исходов. В первом случае вас поблагодарили, стали относиться лучше, стали давать похожие задачи и всячески мотивировать. Бывает, что ничего не меняется кроме осознания, что у вас больше времени свободного и давай ка мы нагрузим вас всякими другими задачами (армейский вариант: кто не курит - тот копает). Честно говоря, ни разу не видел вариантов с увольнением после таких ситуаций, но не отрицаю, что такое может быть. Со мной лично была ситуация, что написанное мною требовалось при увольнении с мотивацией "это делалось в рабочее время на рабочем оборудовании" и не взирая на то, что все вокруг имеют такое же рабочее время и такое же оборудование, но делают это руками (не говоря уже о том, что работы много, и делал я это дома по вечерам). Бывшему руководителю я сказал, что всё снёс и это не вернуть, но заинтересованным исполнителям копию из бекапа восстановил после личной просьбы.
Разработки много, кодеров мало. Нужно сделать быстро. Сделать хорошо никто не пытается. Поэтому лучшее, что есть сейчас в винде - это то, что Майкрософт сделали опенсорсным и оно развивается сообществом (powershell, wsl, windows terminal).
С другой стороны сами подумайте: производители железок делают миллиарды товаров ежедневно. Кто-то должен это покупать. Ну наймут мс на рефакторинг кучу инженеров. Потратят денег. Сделают хорошо. И тут придут производители железа, потому что людям больше не нужно повально добавлять цпу и ОЗУ.
С третьей стороны: отказ от поддержки старых процессоров (даже двухлетней давности) - это как раз таки попытка рефакторинга с выкидыванием старых инструкций. Через одно место, конечно, как и многое у МС и винды, но это именно с теми целями. Десяточка для старых, 11 для будущего (слоган не мой)
>Мозила открывает https, как браузер по умолчанию.
Мне, как пользователю, хотелось бы что бы при использовании строки поиска на панеле пуск или в меню пуск - поиск открывался в браузере по-умолчанию. Но увы. И вместо того, что бы дать возможность сделать это - МС ещё и усугубляет ситуацию.
Да о чем тут говорить: с хрюши хочется, что бы по нажатию win+e открывался фар, а не эксплорер. Но нельзя. Зашито, захардкожено, забито гвоздями.
И это претензия к МС, а не запрет автоматической смены браузера по-умолчанию. Претензия к созданию протокола, хотя та же информация доступна с любого другого браузера. И если так - то почему нельзя открывать это в любом другом браузере по ссылке из интерфейса?
Я не синьор (да и вообще не программист официально), но для меня лично переломным стало понимание того, что нужно прочитать и осознать что тебе пишет компилятор/интерпретатор (а если есть возможность - то вообще линтер). Причем сделать это перед тем, как гуглить. Возможно и гуглить не нужно будет, и в голове больше отложится.
Ну в таком случае давайте разделять "привычнее" и "удобнее" :)
ssh-config будет работать в cmd/powershell/WindowsTerminal с маленьким хаком будет автоматически загребать изменения и работать в любом запущенном инстансе wsl. Будет работать для ssh/scp/sftp/sshfs. Будет работать если вы пришли на домашнюю машину через ssh с любого другого места, вплоть до подключения домой с телефона (я пользуюсь JuiceSSH). А скопировав с помощью scp его на другой линуксовый хост - он будет работать и на том хосте.
Из обязательного, что нашел через промежуток времени после написания комментария: нужно проверять на наличие файла перед ffmpeg. Если файла нет - выходить с указанием, что файл не найден.
Из необязательного, но было бы правильно: после ffmpeg'а и обрезания вывода проверить переменную dur на соответствие регулярному выражению.
Из вообще мелочей: их много, но больше всего меня беспокоит две. 1) заменить
'%H:%M:%S'на'%T'; 2) Всё таки попробовать заменить все bc на $(()), если получится (лень проверять сейчас). Первое визуально сократит код, второе может сделать его быстрее, потому что вызов отдельного приложения - всегда накладные расходы и время. Одна только замена в вызове date после собаки на$(($step * 15))- уже дает почти двухкратное увеличение скорости выполнения на небольшом файле (длительность 3:23):Кстати, пока писал коммент - обнаружил, что скрипт автора выводит время сверху длительности файла. Т.е. мой файл 3:23, скрипт автора последним таймингом выводит 3:30. Я что бы этому соответствовать - добавил в вычисление steps +1. Его нужно убрать, потому что это, имхо, неверно.
Я лишь пытался намекнуть, что многое можно сделать проще, а многое лучше. Я тоже не программист. Мне понадобилось определенное время, что бы написать тот код, который я приведу ниже. Сделал это исключительно ради освежения своих знаний.
Сделал нарочито просто, без сокращений. Уверен, что можно написать красивее (но понимать "непрограммисту" будет сложнее). Знаю, что можно написать короче. Подозреваю, что мой код тоже не идеален, и его улучшать и улучшать.
Первый блок кода это usage - он не нужен для работы скрипта, но сильно помогает когда им делишься. Потом с помощью ffmpeg (который вы использовали) мы получаем длительность. Не понятно, зачем вы в вашем решении били на отрезки, зачем потом проверяли наличие отрезков. Это всё вычислительные ресурсы, которые не нужны. Дальше используя количество шагов мы просто выводим тайминги с нужным вам форматом. Всё. Если нужно решить конкретно вашу задачу - то даже такое решение уже сильно проще. Имхо, читаемее.
Попробуйте воспринимать это не через призму критики ради вашего оскорбления, а с призмы попытки подсказать вам, что можно сделать лучше в будущем. У меня не было цели вас задеть.
это да, но...
ssh клиент в винде уже научился понимать ssh-config (~/.ssh/config). Там намного удобнее прописать конкретные настройки хоста и туннелирование. Бонусом: эти конфиги будут прекрасно работать на любом линуксе с openssh
Зашел попробовать, первую партию слил очень быстро. Начал искать варианты, но со второй партии стал ощущать, что бот, похоже, видит всю доску. Слишком "дерзкие" атаки. Еще очень сильно сбивает, когда "туман войны" появляется в твоих рядах. Головой я помню расположение, и знаю, что там ничего нет (во всяком случае в начале игры). Но очень сильно сбивает. В общем после еще ряда попыток устал, пошел дочитывать комментарий, и аж отлегло. Бот таки видит всю доску, и это многое объясняет. Много думал над разработкой бота для старкрфта, так вот там если самому простому боту включить "мапхак" - то он с легкостью выносит противников, которые гораздо сильнее его (впрочем, с людьми это работает ровно так же).
Рискую быть обвинен в занудстве, но есть несколько вопросов/предложений:
>Обычно работа по транскрибации оплачивается по времени записи. Было бы удобно сразу после завершения работы видеть и сумму, которую вам должен будет заплатить заказчик.
>Скрипт определяет стоимость работы исходя из расценки 17 р/мин. Эта цена настраивается в строке 65 указанием цены за 15 секунд.
Почему бы сразу не взять длительность файла в минутах (с округлением вверх) и не умножить ее на 17? Весь блок кода будет заменен одной строкой, не будет дробных чисел, и в целом всё будет сильно читабельнее.
>Имя аудио файла не должно содержать пробелов и лишних точек
Так же как и с выходящим файлом - лучше просто разобраться как работать с файлами, содержащими пробелы и другие символы. Было бы и более "юзерфрендли" и больше "защиты от дурака".
Я попробовал запустить скрипт, и получил чистый экран терминала. Предварительно вывалилась какая-то ошибка (ffmpeg вроде). И ничего больше. В целом-то понятно, что ему нужно передать какой-то аргумент, но сам скрипт ничего не ответил на эту тему. Хорошей практикой будет сделать проверку на наличие аргумента, и в случае его отсутствия выдать usage. Вы же сами, если какое-то время не будете пользоваться своей наработкой - забудете/запутаетесь. Придется открывать код и вспоминать. Так вы еще и презентуете это, а раз так - то неплохо бы сделать хорошо :)
В принципе очень много беспорядка в коде. Лишние комментарии, лишние пробелы, отступы, неочевидные конструкции, общая "неоднородность" кода. Например, что делает команда эта команда?
А точнее ее первая часть. Зачем она тут нужна? Зачем столько лишних символов во второй части?
cat text_1.txt >> $BNAME.txtсработает так же. Аcat file >> "${BNAME}.txt"еще и без проблем сработает при файле с пробелом.Почему в каких-то случаях использована конструкция
$(command)а в каких-то`command`? Рекомендации к использованию парных скобок $() давно описаны, их легче дебажить, чем непарные ``. Почему переменные стилистически используются по-разному? Когда ${var}, когда $var. Есть понимание, или это "от балды"? Зачем конструкции типаF_NAME_FULL="./"$BNAME"."$EXT, если ее заменитF_NAME_FULL=$BNAME.$EXT? Если хочется извращаться с точка-слеш перед названием файла (хотя нужно понять зачем это делать) - то хватит"./${BNAME}.${EXT}". Возможно ли все "математические" операции привести к одному виду, что бы использовать что-то одно из expr, bc, $(())? Конструкция(echo "X")>>./text_1.txtвообще феерична :) Зачем грузить во временные файлы всё, если можно грузить в память? В случае если скрипт сломается посредине (или будет остановлен) - хотя бы не останется кучки мусора. В конце концов зачем clear в конце? Может я логи почитать хочу :) без tmux'а я бы этого сделать не смог.Мне кажется, что если навести порядок в коде - статья уже будет иметь большую ценность, хотя бы с точки зрения самообразования автора.
В заключение: при всей моей любви к башу в целом, при тысячах строк написанных мною в собственных баш-портянках - сегодня подобное я бы стал делать только если хочется потренировать непосредственно баш. Если бы мне нужно было решать задачу - я бы, вероятнее, взял пайтон, начал с малого, но двигался бы в сторону автоматического определения наличия разговора в определенном временном диапазоне, динамическое создание таких временных диапазонов, и, возможно, автоматический перевод аудио в текст. После чего просто подредактировать тайминги там, где это нужно и отдать корректору (или самому) на корректирование ошибок автоматического преобразования. А может быть в сторону интерактивности, где после определения временного диапазона этот диапазон проигрывается в цикле, а в окошке есть возможность сразу редактировать временной интервал и "распознанный" текст. На сегодняшний день это звучит вполне реальной задачей.
На старой ленове х230 есть кнопка :)
Есть микрофоны с аппаратным отключением звука. Есть внешние звуковые карты (у меня стоит 2i2, я вполне доволен, но это решение для стационарных ПК)
Ещё можно выключать на уровне ОС. Под линуксом, думаю, объяснять не нужно. Под виндой я написал себе маленький скрипт на AHK, собрал в бинарь и использую его что бы сделать мьют микрофона на уровне ОС. Да, это не 100% гарантия, что микрофон не сможет использовать телеметрия майкрософтов, но с таким подходом ни гугл-митс ни зум ни цискомит до звука не добираются. Гугл видит что микрофон в мьюте и регулярно на это ругается)) А вообще такое решение имеет дополнительный плюс: один хоткей на выключение микрофона во всех приложениях, и работает он в любом окне системы (думаю всем знакома ситуация, когда у тебя что-то спрашивают, а ты в другом окне и судорожно начинаешь искать вкладку в хроме, в которой мит)
Подозреваю, вы делали покупки под какие-то распродажи типо 11-11. Многие банки под такие события выключают проверку лимитов и отменяют 3дс до определенных сумм (20-50$ на одну операцию). Мотивируют это удобством клиента. На самом деле разгружают поток обращений в коллцентре. Малый процент недовольных слихвой покрывается большим количеством транзакций, с которых банк заработает. Единицы дойдущие до суда - скорее всего проиграют. Кому-то, возможно, вернут. Но для банка это копейки. А заработал он много.
Вы либо читаете через строку, либо занимаетесь перекручиванием. Потому что в моем комментарии таких посылов нет, особенно про наказание.
Идеальный вариант для меня - развитие общественного транспорта и велоинфраструктуры. И значительное уменьшение доли персонального транспорта на дорогах. Снижение максимальной разрешенной скорости в городе. Реально большие штрафы за нарушения. Неизбежность наказания за нарушения. Вот это - идеальный вариант для меня.
А по поводу "таких городов не существует" - есть города, которые к этому стремятся. И качество жизни в таких городах сильно выше дефолт-сити и городов тех стран, которые идут по ошибочному пути строительства дорог ради решения проблем пробок (что, ожидаемо, приводит только к увеличению пробок). Вы можете не доверять мне и моим словам, это нормально. Но для вас тысячи статей по урбанистике написаны. С исследованиями и доказательствами. Почитайте про концепцию Vision Zero. Почитайте другие материалы по урбанистике, хотя бы для общего развития. И вы увидите логику повествования и проблемное направление текущего развития городов постсоветского пространства. Да, господи, даже автор поста достаточно сумбурно накопипастил фраз из источников, которые он указал внизу статьи.
PS. Наперед отвечая на вопросы, которые неизбежно появляются в рамках любой похожей дискуссии: у меня есть автомобиль. Хороший. В семье даже не один. Да, я езжу на нем (примерно тысяч по 30 в год, что выше среднего показателя). Но при этом я всё равно за "ущемление" автомобилистов ради пешеходов/велосипедистов/общественного транспорта. Ибо именно это, как правило, приводит к решению вопроса пробок.
Штрафы копеечные. Штраф за угрозу жизни окружающим (читай стрельба в общественном месте) после 50% скидки сколько? 10-12 баксов? Да частью людей это воспринимается не как штрафы, а как плату за нарушение. Такая себе выделенная платная дорога. Только не выделенная. Штрафы за парковку значительные только если эвакуатор забрал. Гайки не то, что затянуты - они разболтаны и вот-вот сорвутся.
> Поэтому все эти вопросы штрафов, наказаний и т.д. - это вопрос балансов. И если в какой-то момент резьба становится перезатянутой, она ломается.
Мне кажется, что эта мысль близка к правильной. Но либо я пропустил абзац, либо предложения сделать штрафы слишком большими - не было. При этом, мы видим страны, которые пользуются знаниями и выводами такой сферы, как урбанистика. Более того, мы любим отдыхать именно в таких странах. Нам классно, когда машин и дорог меньше, вело/пешеходных и зеленых зон - больше.
Живем-то мы тут. И пока мы опустив руки будем говорить "живем-то мы тут, ничего не изменить" - ничего и не поменяется. Более того, у нас есть примеры и опыт тех стран, которые на правильном пути. Страны, в которых закон более работоспособен. Можно было бы учиться на чужих ошибках, но мы так не умеем.
К сожалению, автор поста по непонятной причине спорит со всеми, не придавая значения тому, что он попытался сложные вещи описать простым языком, получилось всё равно сложно, еще более запутано и местами весьма криво :)
Итогом получаем неплохую, но бесполезную тему для обсуждения в таком ключе. Новичку в музыке я бы не рекомендовал читать это, только запутает
В подтверждение ваших слов: тут есть влияние опыта. Запись музыки нотами примерно аналогична записи слов буквами. Опытный читатель вполне осилит проговорить у себя в голове то, что написано буквами. И наоборот, мы думаем не проговаривая слова, и сразу печатаем их в текст. Так и опытный композитор в голове проигрывает мелодию, и если она ему нравится - переписывает на бумагу. Технически - сразу нотами на бумагу. Фактически - до этого происходит мозговая активность что бы понять, что именно написать.
У ИТ отдела как правило не один заказчик. Но другие ведь справляются :)
Что бы понять чьи хотелки делать раньше - нужен некий скоринг заявок. Лучше, если этот скоринг будет делать бизнес. Если есть единый руководитель бизнеса - то в итоге он. Если нет - то пусть руководители бизнесов собираются и обсуждают друг с другом кто важнее.
А вот занятость разработчиков не волнует тех, кто сверху, пока руководитель разработчиков не может правильно донести до верхов текущую ситуацию.
Я больше скажу, в этих двух статьях даже некоторые комментарии с минимальными отличиями :D
Ну у вас ведь есть система ведения отчетности о проделанной работе? Система трекинга времени? Если новые вещи не имплементируются или задачи выполняются долго - то нужно показать почему. Если отдел из N разработчиков тратит время на поддержку старых продуктов - то, к сожалению для них [разработчиков этого отдела], они должны доносить об этом руководству/заказчику. И либо нанимайте доп.персонал, либо откладываем реализацию новых фич и занимаемся рефакторингом старых проектов. Как правило, после рефакторинга оказывается, что как минимум третью уже никто не пользуется, еще третью пользуются единицы, а еще треть - это дублирующий функционал. Можно напрячься, сделать самим, нарисовать красивую презентацию о проделанной работе и прийти к руководству с запросом на повышение. В зависимости от развития событий - принимать соответствующие решения.
На моем опыте чаще компании (или руководители подразделений в больших компаниях) даже не знают о такой возможности. А потом "а что, так можно было?". И тут несколько исходов. В первом случае вас поблагодарили, стали относиться лучше, стали давать похожие задачи и всячески мотивировать. Бывает, что ничего не меняется кроме осознания, что у вас больше времени свободного и давай ка мы нагрузим вас всякими другими задачами (армейский вариант: кто не курит - тот копает). Честно говоря, ни разу не видел вариантов с увольнением после таких ситуаций, но не отрицаю, что такое может быть. Со мной лично была ситуация, что написанное мною требовалось при увольнении с мотивацией "это делалось в рабочее время на рабочем оборудовании" и не взирая на то, что все вокруг имеют такое же рабочее время и такое же оборудование, но делают это руками (не говоря уже о том, что работы много, и делал я это дома по вечерам). Бывшему руководителю я сказал, что всё снёс и это не вернуть, но заинтересованным исполнителям копию из бекапа восстановил после личной просьбы.
Разработки много, кодеров мало. Нужно сделать быстро. Сделать хорошо никто не пытается. Поэтому лучшее, что есть сейчас в винде - это то, что Майкрософт сделали опенсорсным и оно развивается сообществом (powershell, wsl, windows terminal).
С другой стороны сами подумайте: производители железок делают миллиарды товаров ежедневно. Кто-то должен это покупать. Ну наймут мс на рефакторинг кучу инженеров. Потратят денег. Сделают хорошо. И тут придут производители железа, потому что людям больше не нужно повально добавлять цпу и ОЗУ.
С третьей стороны: отказ от поддержки старых процессоров (даже двухлетней давности) - это как раз таки попытка рефакторинга с выкидыванием старых инструкций. Через одно место, конечно, как и многое у МС и винды, но это именно с теми целями. Десяточка для старых, 11 для будущего (слоган не мой)
>Мозила открывает https, как браузер по умолчанию.
Мне, как пользователю, хотелось бы что бы при использовании строки поиска на панеле пуск или в меню пуск - поиск открывался в браузере по-умолчанию. Но увы. И вместо того, что бы дать возможность сделать это - МС ещё и усугубляет ситуацию.
Да о чем тут говорить: с хрюши хочется, что бы по нажатию win+e открывался фар, а не эксплорер. Но нельзя. Зашито, захардкожено, забито гвоздями.
И это претензия к МС, а не запрет автоматической смены браузера по-умолчанию. Претензия к созданию протокола, хотя та же информация доступна с любого другого браузера. И если так - то почему нельзя открывать это в любом другом браузере по ссылке из интерфейса?