Это устойчивая шутка из RPG игр же) см. make love, not warcraft в южном парке
Если бы я считал кого-то врагами, я бы не делился интересными материалами, не создавал бы сам бесплатный курс, не записывал видосы. Наоборот, я всячески ратую за распространение знаний
Кстати, записать и выложить интервью - законно? Вроде как без уведомления второй стороны не очень, но конкретных законов на этот счёт я не знаю. И не знаю, как к этому отнесутся люди. Знаете что-нибудь на этот счёт?
по поводу смежных команд. я и не понесу им внутрянку. Со смежными командами мы будем смотреть на более верхнеуровневую схему, где будет отражена информация полезная именно им, как внешним ребятам
Категорически согласен насчёт важности работы аналитиков, особенно если есть и бизнес, и системные аналитики - важно, чтобы знания не просыпались при передаче артефактов.
Как вы понимаете на этот счет прямого ответа нет))
У нас очень квалифицированные manual qa. Они очень хорошо знают продукт, очень дотошно изучают требования на разработку, участвуют в разборе инцидентов на линиях поддержки. И по сути благодаря им получается выявлять и сокращать количество кейсов, о которых никто не подумал ранее.
Конечно кажется уже поздновато - на этапе тестирования, но это точно лучше, чем в проде.
Хороший пример задачи, которой нужны детали. Ладно, если Оля одна, это не требуется уточнять. Но где её встретить? Во сколько? Нужно ли что-то с собой взять? Вот эти детали, вписанные в задачу, позволяют далее не думать, а просто делать
Да с точки зрения рисков вы, безусловно, правы. Но тут по факту рандом – компания может начать блокировать и выгонять кого угодно, может вмешаться РКН и вообще может произойти что угодно. В этом смысле прописка команды разработчиков мало на что повлияет. Чтобы купировать риски, стоит смотреть только self-hosted решения с открытым исходным кодом, и мириться с отсутствием нужного функционала. Вы знаете или пользуетесь такими?
Мне, конечно, будет обидно потерять историю задач, но я довольно быстро смогу мигрировать куда угодно. Потеряв в удобстве, понятное дело
Who cares? В США разрабатывают довольно много софта и проектируют много железа. На минуточку, Intel и AMD американские, а без процессоров от них, весьма вероятно, не работал бы ни этот сайт, ни ваше устройство
На вкус и цвет – годится любой таск менеджер, если вам в нём работать удобно) мне очень зашёл ТикТик, плачу за подписку. Хотя глобально, вроде как, этот тракт в любом такс-менеджере можно запилить
uniq -c к каждой строке дописывает число раз, которое строка встречается. При этом он выводит все строки. Ответа в виде "всего X уникальных строк" этой командой не получить
Кстати, вы пробовали, сколько по времени выводится 10+ млн строк? Это занимает довольно много времени
Проблема будет в тот момент, когда пользователь обновит версию питона или версию используемой библиотеки. Тогда системная утилита рискует отвалиться в самый неожиданный момент. Случай редкий нынче, но раньше такое было сплошь и рядом
Да, общая терминология - это важно во многих случаях. Конкретно эта троица так друг в друга проросла, что вот линейка "вы запускаете GUI terminal emulator, оно запускает shell, который обычно bash как конкретная реализация шелла" в среднем неважна. В плане, на GUI обычно плевать (ну, вот я использую terminator, но я оттуда юзаю infinite scroll, цвет, split screen, вроде всё). Дальше, те, кто знаком с не-bash шеллами, понимают, о чём речь при вопросе bash vs shell. Для остальных это всё терминал и всё
Спасибо за статью. Всегда искал, куда людей про TTY тыкать, т.к. на пальцах я только на уровне "ну, это такое устройство псевдо-файл и он есть по историческим причинам" могу объяснить
Блин, точно. По поведению nohup ещё в студенческие годы десять лет назад я ошибочно решил, что оно делает отвязку от родительского процесса, что-то вроде double fork для создания процесса-демона. Был не прав, блокируется сигнал о потере управляющего терминала
В среднем, не понимаю терминологических споров на пустом месте. А терминал - это устройство. Программа, о которой говорите вы - это эмулятор терминала.
Не вижу смысла разводить демагогию bash vs shell vs terminal
Подскажите, где именно я предлагаю не POSIX-решение?
GUI приходится учить. Любая сложная программа требует времени на освоение. А потом меняет интерфейс и всё по новой. Даже word редизайнился уже столько раз, что грустно об этом говорить. А сила bash в том, что приобретённые знания будут с вами десятки лет. Это, конечно, тянет назад огромным количеством легаси. Но для других языков, вы к курсе, через 10 лет уже не запустить свои наработки - в языках всё меняется
А docker для backend dev / datascience насколько сейчас глубоко врос, как и гит. Не знаю, где посмотреть свежую аналитику, но docker уже давно в backend developer roadmap и в 50%+ вакансий
Это устойчивая шутка из RPG игр же) см. make love, not warcraft в южном парке
Если бы я считал кого-то врагами, я бы не делился интересными материалами, не создавал бы сам бесплатный курс, не записывал видосы. Наоборот, я всячески ратую за распространение знаний
Хех, доп. монетизация подъехала
Кстати, записать и выложить интервью - законно? Вроде как без уведомления второй стороны не очень, но конкретных законов на этот счёт я не знаю. И не знаю, как к этому отнесутся люди. Знаете что-нибудь на этот счёт?
по поводу смежных команд. я и не понесу им внутрянку. Со смежными командами мы будем смотреть на более верхнеуровневую схему, где будет отражена информация полезная именно им, как внешним ребятам
Категорически согласен насчёт важности работы аналитиков, особенно если есть и бизнес, и системные аналитики - важно, чтобы знания не просыпались при передаче артефактов.
Как вы понимаете на этот счет прямого ответа нет))
У нас очень квалифицированные manual qa. Они очень хорошо знают продукт, очень дотошно изучают требования на разработку, участвуют в разборе инцидентов на линиях поддержки. И по сути благодаря им получается выявлять и сокращать количество кейсов, о которых никто не подумал ранее.
Конечно кажется уже поздновато - на этапе тестирования, но это точно лучше, чем в проде.
Хороший пример задачи, которой нужны детали. Ладно, если Оля одна, это не требуется уточнять. Но где её встретить? Во сколько? Нужно ли что-то с собой взять? Вот эти детали, вписанные в задачу, позволяют далее не думать, а просто делать
Конечно, приёмник – не радиоволны же
Но радио Попов изобрёл!
Да с точки зрения рисков вы, безусловно, правы. Но тут по факту рандом – компания может начать блокировать и выгонять кого угодно, может вмешаться РКН и вообще может произойти что угодно. В этом смысле прописка команды разработчиков мало на что повлияет. Чтобы купировать риски, стоит смотреть только self-hosted решения с открытым исходным кодом, и мириться с отсутствием нужного функционала. Вы знаете или пользуетесь такими?
Мне, конечно, будет обидно потерять историю задач, но я довольно быстро смогу мигрировать куда угодно. Потеряв в удобстве, понятное дело
Who cares? В США разрабатывают довольно много софта и проектируют много железа. На минуточку, Intel и AMD американские, а без процессоров от них, весьма вероятно, не работал бы ни этот сайт, ни ваше устройство
На вкус и цвет – годится любой таск менеджер, если вам в нём работать удобно) мне очень зашёл ТикТик, плачу за подписку. Хотя глобально, вроде как, этот тракт в любом такс-менеджере можно запилить
uniq -c к каждой строке дописывает число раз, которое строка встречается. При этом он выводит все строки. Ответа в виде "всего X уникальных строк" этой командой не получить
Кстати, вы пробовали, сколько по времени выводится 10+ млн строк? Это занимает довольно много времени
Проблема будет в тот момент, когда пользователь обновит версию питона или версию используемой библиотеки. Тогда системная утилита рискует отвалиться в самый неожиданный момент. Случай редкий нынче, но раньше такое было сплошь и рядом
Плохо - это в концепции EEE разрушить линукс-сообщество, замкнув всё на себя
Да, ls -1 везде существует. А sort -1 в специфических ситуациях :)
Спасибо, это решение (если не надо смотреть в подкаталоги) куда более изящное
Да, общая терминология - это важно во многих случаях. Конкретно эта троица так друг в друга проросла, что вот линейка "вы запускаете GUI terminal emulator, оно запускает shell, который обычно bash как конкретная реализация шелла" в среднем неважна. В плане, на GUI обычно плевать (ну, вот я использую terminator, но я оттуда юзаю infinite scroll, цвет, split screen, вроде всё). Дальше, те, кто знаком с не-bash шеллами, понимают, о чём речь при вопросе bash vs shell. Для остальных это всё терминал и всё
Спасибо за статью. Всегда искал, куда людей про TTY тыкать, т.к. на пальцах я только на уровне "ну, это такое устройство псевдо-файл и он есть по историческим причинам" могу объяснить
ubuntu 18.04, kernel 4.16, sort -1 нет
Блин, точно. По поведению nohup ещё в студенческие годы десять лет назад я ошибочно решил, что оно делает отвязку от родительского процесса, что-то вроде double fork для создания процесса-демона. Был не прав, блокируется сигнал о потере управляющего терминала
В среднем, не понимаю терминологических споров на пустом месте. А терминал - это устройство. Программа, о которой говорите вы - это эмулятор терминала.
Не вижу смысла разводить демагогию bash vs shell vs terminal
Подскажите, где именно я предлагаю не POSIX-решение?
GUI приходится учить. Любая сложная программа требует времени на освоение. А потом меняет интерфейс и всё по новой. Даже word редизайнился уже столько раз, что грустно об этом говорить. А сила bash в том, что приобретённые знания будут с вами десятки лет. Это, конечно, тянет назад огромным количеством легаси. Но для других языков, вы к курсе, через 10 лет уже не запустить свои наработки - в языках всё меняется
А docker для backend dev / datascience насколько сейчас глубоко врос, как и гит. Не знаю, где посмотреть свежую аналитику, но docker уже давно в backend developer roadmap и в 50%+ вакансий