Если вручную: Теоретически и практически возможно (крючком, спицами сложнее, но тоже можно). Даже как минимум двумя способами. Но удобство процесса и качество результата будет сомнительными.
От первой манжеты рукава по кругу; потом туда-сюда всей высоте "тела", делая соответствующие изменения рядов для создания выреза под голову/шею; связать сначала, например, половину переда (под шеей), затем закрыть петли у шеи и перейти к вязке спины, обе половины под шеей, затем набрать доп петли (для компенсации закрытых и убавленных), довязать вторую половину переда, потом опять туда-сюда, затем нужно как-то аккуратно сшить бок, оставив петли для круговой вязки рукава; дальше второй рукав и манжету.
Второй способ - то же самое, но "тело" вязать не прямыми рядами, а диагональными; так можно и шва бокового лишиться.
Но сразу скажу: никакой симметрии узора и эстетики в таком не будет, изначально так себе затея вязать всё одной деталью.
P.S. текст - личное мнение; если есть способы сделать свитер крутым одной деталью - с интересом прочитаю описание сего процесса.
В Windows всё ровно то же: чтобы заработало какое-то новое устройство, для него нужны драйверы, которых по умолчанию может не оказаться в системе.
Некоторые драйверы содержатся в ядре ОС, да. Ядро ОС можно поставить новое из интерфейса, при включении устройства выбирать с каким ядром загружать систему. Если не понравится - можно удалить.
Список доступных Linux Kernel для установки
Часто про семейство дистрибутивов линукс говорят что-то, что справедливо и для Windows, только в Windows с этим реже сталкивались, т.к. ОС предустановлена = проверена для того железа, на котором установлена, вот и вся разница.
Мне несколько раз приходилось на винде обновлять драйверы для монитора и для каких-то устройств ввода (не помню) - то ещё развлечение; в linux это делается, обычно, одной командой, а не гуглежом на 20-30 минут и несколькими попытками "это оно или нет? всё уже?".
Похоже на то, что ядро старое было. Новое железо поддерживается новыми ядрами ОС. Многие дистрибутивы (даже в новых версиях) используют какие-то древние (стабильные, проверенные) ядра. Про зависание: предполагаю, проблема была связана либо с драйверами процессора (проприетарные нужно ставить самостоятельно), либо с драйверами кулера - новые в новом ядре.
С принтерами в Linux сталкивался только один раз - беспроводной большой МФУ. Из проблем: искать драйвер долго, но я его нашёл) Но понимаю, что принтеров много, дистрибутивы разные и так далее.
На ручных вязальных машинах такие можно вязать. Автоматически, в целом, тоже можно было бы вязать, думаю - тут только вопрос выгоды, не вижу особых сложностей.
Перчатки и варежки же вяжут автоматически - там тоже динамический размер рядов.
И всё же хочется вязальную машинку, которая вязала бы "крючком". С точки зрения робототехники это более интересная задача. С точки зрения конечной продукции - тоже, т.к. крючком можно делать более сложные формы - игрушки, чехлы произвольной формы, более "воздушные" изделия ("спицами" получаются более замороченные и менее надёжные). Автоматических вязальных машин "спицами" уже существует большое кол-во. Вязальных машин крючком не встречал - это сильно удешевило бы процесс создания таких изделий (конечно, при условии, что амортизация стоимости такой машинки не перекроет всю выгоду от экономии на ручном труде).
Основная цель законопроекта - предприниматели, а не конечные пользователи. Это нужно и чтобы рынок не штормило от постоянных колебаний "д вроде норм площадка" - "никогда больше сюда не приду, ухожу к другим" - "другие ещё хуже, буду продавать сам" - "д вроде норм маркетплейс был, что они там предлагают" - "какие же у них конские ценники и зверские условия, ухожу!" - ...; и "защита прав индивидуальных предпринимателей" (де юре) - забрать самодеятельный произвол каждой из площадок и установить единые правила. Этой функцией (устанавливать такие правила), напоминаю, по самой идее государственности, обладает/должно обладать государство. Как они придумывают эти законы? Берут опыт у больших частных первопроходцев, которые поначалу придумывают правила сами и по ситуации их потом меняют. Когда правила настоялись и начинается произвол - вступает государство.
Почему с ОпСоСами не так? У них рынок поделён, не штормит, кому надо "дань" идёт за монополию хамское поведение с их стороны, основной "регулятор" ОпСоСов - ГРЧЦ - гос компания. Основные ОпСоСы (как и банки) "принадлежат" аффилированным с гос-вом компаниям (через ВТБ и ГазпромБанк как акционеров, через дружественных олигархов и их АФК "Система", "МеталлинвестБанк" и прочее).
Озон и WB - условно "независимые" площадки. А ещё подобных площадок у кого только нет - ВК, Сбер, Яндекс, Авито, Юла, АлиЭкспресс, Амазон и так далее - их проще контролировать не договорняком, а более открытым и общим механизмом - законами.
Если про услуги в общем смысле, то общий механизм: на всё не хватает времени, денег и людей, готовых это исполнять, выставляют приоритеты. С начала 2022 сами понимаете какие приоритеты - удерживать устойчивость общества и страны; что не мешает активно вкладываться в инфраструктурные проекты (я лично это всё видел и был слегка в шоке от их кол-ва. Хотя качество в таком случае страдает, да).
Вы привели пример про "вам нужен костёр? Вам он не нужен, вот есть спички - тут тоже есть огонь" и я про это не писал - само собой опыт должен быть сопоставим с уровнем ответственности и компетенциями.
Но часто происходит "шашечки или ехать": - мне нужен костёр, мне написали, что на костре можно разогреть еду. - предлагаю вам газовую горелку, она безопаснее, сразу даёт тепло, сразу можно убрать огонь, если надо - одни плюсы! - не, мне написали, что нужен костёр, притом на берёзовых поленьях. Про газовую горелку ничего не написано, поэтому "вы нам не подходите".
Хотя очевидно, что в этом примере нужна функция - разогреть еду. Тут и микроволновка могла подойти, и паровая баня и всё что угодно, выполняющее функцию.
Любой опытный Java программист, претендующий на программирование серверов на Go с описанием того, что он в экосистеме Go разбирается или может освоиться (в курсе из чего экосистема состоит), скорее всего понимает на что он идёт и, значит, нужно рассмотреть вариант дообучить его до нужной лёгкости владения инструментами экосистемы Go и провести техническое собеседование, а не послать его куда подальше, потому что "к сожалению, у вас недостаточно опыта программирования на Go, а менеджеру это очень нужно". И неважно, если этот разработчик очень хорош в программировании серверных микросервисов/модулей, особенно многопоточных и без гонки данных.
Гораздо ценнее разработчик, который на практике владеет методами предотвращения гонки данных в любых системах (в которых они теоретически возможны), чем разработчик, подходящий под описание "имеет опыт работы на Go не меньше двух лет". Но поди объясни это менеджеру или HR'ам...
Первая причина, почему рекрутеры не приглашают на интервью — нерелевантный опыт. Кандидат не подходит по скиллам, проектам или у него не такой серьезный стаж работы, чем компания ожидает.
Стереотипы, шаблонность, уравниловка. Вы ищете идеально подходящего кандидата по какому-то не обязательно идеальному описанию или того, кто будет работать?
Профессия требует постоянного обучения: мы читаем статьи и проходим дорогие курсы. Тратим время и ресурсы, чтобы говорить с соискателями на одном языке, понимать стеки. Если рекрутер этого не делает, то задает на собеседовании глупые вопросы, ...
Не те курсы, видимо, проходите. Программирование серверов, сайтов и игр, в сущности своей, имеет сильно больше общего, чем различий. Программирование из написания кода на каком-то языке состоит процентов на 15-20. С хорошими ТЗ и тестировщиками может процентов на 30-40. Всё остальное время - обсуждение задач, проектирование логики, обсуждение требований, тестирование, дебаггинг (он на всех языках одного класса (императивные, например) одинаковый. Мне, помнится, приходилось дебажить код на С++, когда я его ещё не знал (знал Java7), исправил исходный код, перекомпилировал и запустил в работу платформу, на которой в итоге работал с целевым ЯП (не C++)), описание багов, приоритезация задач (у кого побольше опыта), системный анализ (который уже не может делать аналитик из-за технических тонкостей), оптимизация алгоритмов/процессов (это вообще общеинженерный навык, не только айтишный), проведение экспериментов и продуктовых тестов (профиль нагрузки, latency, отказоустойчивость), написание первичной документации.
И даже писанина на каком-то языке или на какой-то платформе состоит не из знания перечня всех возможных функций и их аргументов на этой технологии, а из общего знания "что должно быть, как это должно работать, в теории". Любой опытный айтишник запросто сменит свою проф. область за месяц-полтора-два при должной мотивации.
Но HR рынок по-прежнему продолжают искать по принципу:
Первая причина, почему рекрутеры не приглашают на интервью — нерелевантный опыт. Кандидат не подходит по скиллам, проектам или у него не такой серьезный стаж работы, чем компания ожидает.
Стаж работы? За 1 год интенсивной R&D работы можно изучить раз в 10 больше, чем за 5 лет поддержки готового legacy кода. Неужели менеджеры в IT этого не понимают? Сомневаюсь.
Все люди разные. Некоторые способны программировать на технологиях, которые впервые в жизни видят, а некоторые с уже хорошо знакомыми технологиями чуть в сторону отойти не могут - "этим всегда DevOps/тестировщик/аналитик/архитектор занимался, я не знаю ничего оттуда". Но "стаж", "опыт", "проекты"...
...недавно мы публиковали чек-лист, который помогает усилить резюме
Нет! Называйте вещи своими именами: это чеклист, который позволяет HR проще отсеивать тех, кто не подходит под ваши шаблоны. Для кандидатов такие рекомендации не помогают!
У меня есть два резюме: в одном я соблюдал все возможные рекомендации - более "образцового" резюме не найти. На 140+ моих откликов штук 70 молчаливых отказов, около 40 просто тупо игноров, штук 30 опросов от HR, технических собеседований штук 15. Офферов 3-4. Приглашений от HR штук 5 за 4+ месяцев поиска.
Во втором резюме указаны всё те же самые навыки, нет фото, нет описания деятельности в компании, нет описания моих достижений, нет даже ФИО. Это резюме нарушает все возможные рекомендации, кроме одной: указывать свои навыки, которыми я уже владею или способен быстро освоить. Какой результат? 7 приглашений от крупных работадателей за 2 дня. После созвонов (на которых я старался давать минимально возможную и максимально общую информацию, никакого упоминания негатива про кого бы то ни было, даже если его было очень много) технических собеседований из них назначено некоторое кол-во. Сам ещё ни разу не откликался этим резюме.
Так кому вы помогаете своими советами?
И тимлиды ещё "молодцы": отсекают по каждой шероховатости, не стремятся вычленить толковых, стараются найти идеально подходящего под свои шаблоны видения кандидатов (которое тоже не всегда идеально). Даже по тем знаниям, которые гуглятся за 1 минуту и после двух-трех употребление в использовании запоминаются на долгие годы. Может эти статьи по найму лучше не самим усваивать, а стараться научить тимлидов нанимать? За все технические интервью, действительно толковые собеседователи попадались 2 раза. Многие из остальных - опытные нёрды с дутым ЧСВ, либо следующие формальным принакам отбора, которые они составляли как? Методологию проверки знаний тимлиды вряд ли изучают - им же некогда, они же и работают, ещё и уровень кандидатов определять. Особенно, когда нужно вытягивать из кандидатов информацию (а из айтишников надо, коммуникабельных нечасто видел).
И вишенка на торте: тимлиды не учитывают человеческий фактор. Люди - существа эмоциональные и эмоциональное состояние сильно влияет на степень воспроизводства той или иной информации. А ещё частое напряжение памяти и формулирование новых мыслей - очень утомительно. В итоге из-за волнения и перенапряжения человек через 5-10 минут расклеивается, начинает путаться в терминологии, забывает что-то (хотя минут через 10 после завершения с лёгкостью это вспомнит), начинает плохо соображать и всё такое. В итоге может выглядеть (не являться) неопытным, хотя может быть как раз идеально подходящим на роль техлида или ведущего разработчика.
Недавно на технческом интервью через 15 минут после начала переволновался, встал в ступор, в голове пропали все мысли и не смог написать простой SQL запрос, хотя вот только что написал уже несколько не проще этого и полностью назвал алгоритм, как надо его составлять. В итоге тимлид отказал в найме. Через 5 минут после завершения собеса проверил озвученный мной алгоритм - он правильный.
Ещё: есть люди соображающие быстро, а есть, у кого мысли должны повариться и хороший ответ приходит сильно потом. Я из вторых. И в моменте сильно теряюсь, такая вот специфика организма. Из-за этого заваливал многие интервью только потому что не смог сказать синонимичное слово к уже озвученному, а тимлид ожидал услышать именно его.
Рынок IT найма сломан (если хоть когда-то был работающим). И как его чинить/выстраивать - пока непонятно.
Зря я, видимо, перепутал фразу "потоки процессора" и "потоки ОС". И там, и там они называются threads и упомянул пример неаккуратно, да.
Историю выбора слова thread действительно не знал (в работе не пригождалось, акцентов на историю никогда не расставлял, с недавних пор исправляюсь), спасибо за интересную и поучительную историю.
Но всё ещё продолжу утверждать, что слово "thread" как название чего-то "проактивно" действующего (если смотреть со стороны данных в программе) - плохой выбор, т.к. слово thread отображает объект (нитку) и действия, с ним связанные (накручивать и так далее). "Адаптивный перевод" на русский язык чуть более удачный (более физичен и естественен), но создаёт путаницу в уже существующих терминах и не слишком специфично, что можно видеть во всяких шутках типа "управление потока потока разделено на два потока" = "control flow of stream is split between two threads" (подобные конструкции на работе встречались часто, приходилось каждый раз выдумывать как это разделять - это очень неудобно).
Я в курсе (не сильно), что поток/thread (в ОС) это лишь набор инструкций, постоянных и переменных данных, а не исполнитель как вещь в себе, и что фактическую работу ведут процессоры (напару с инструкциями ОС) и генераторы частот.
@shasoftXрассуждал "зачем вводить новые однозначно понятные термины, как их потом обратно переводить и понимать о чём речь?", на что можно парировать: слово поток (как thread) почему-то же уже устраивает, хотя нет таких вариантов обратного "перевода" при переводе на англ. И дальше @gBear пишет
И то, что "потоки" (это которые flow) уже были - никого не смутило,...
А потом пользуйся этим через 20 лет, ага. Уверен, если собраться представителями индустрии, которая производит БД и переводчиками и договориться о терминах всем вместе, то это будет всем на пользу. Да и на другие страны такую практику тоже можно будет перекинуть, если хорошо пойдёт. Master и blacklist переименовали же в main и blocklist всем скопом.
Хотя есть шанс, что где-то останутся "консерваторы" движения "так исторически сложилось" и будут радикально отстаивать, как со словами Ройтерс (Reuters, по ошибке "Рейтер"), Фройд (Freud, "Фрейд") и Айнштайн (Einstein, "Эйнштейн").
Как в таком окружении будешь исправлять свои ошибки, если всё вокруг орёт "да, была ошибка, но все к ней уже привыкли, не надо ничего менять"? Хотя даже Microsoft исправила свою давнюю ошибку.
... вы можете отличить "тред" от "стрима". А вот "поток" от "потока"(?), увы, отличить не получится.
Изначальный перевод слова "thread" не очень удачный просто. А дальше уже "исторически сложилось". Да и сам термин "thread" неудачный. Он же буквально переводится "нить"/"нитка". Вообще, у слова "thread" есть такие переводы, которые выглядят более-менее естественно и на русском языке. Например, "жила". "Для обработки такого потока требуется 10 жил процессоров".
Вообще, раз изначально выбран странный термин, то можно не переводить или адаптировать термин, а изобрести свой, отображающий суть явления, но такой, чтобы неоднозначностей быть не могло. Thread в IT это какой-то трудяга в рамках ОС, но при этом ОС целостная, всем "потокам" достаётся какое-то время процессоров, но фактическими исполнителями (управляющими конструкциями + хранителями стека, кучи и инструкций) являются как раз "потоки". Есть что-то похожее в природе? Ульи! Как тогда можно было бы назвать "потоки"? "Трутень"/"трутни".
"Для обработки этого потока требуется 10 трутней". Вполне звучит, неоднозначностей никаких.
По аналогии можно было бы что-то придумать для различия flow (поток-явление) и stream (поток-процесс).
... исследователи - бездельники... (неточная цитата)
Исследователи исследуют ЦА, не самих себя. Если продукт широкого профиля и заточен на общечеловеческие принципы (не на какую-то специальность), то согласен, что так можно много гипотез получить из первых принципов, но исследования нужны для анализа другого профиля пользователей, для других информационных пузырей и так далее. Есть люди, которые никогда не играли в шутеры или MOBA и для них может быть совершенно непонятно требование пользователей добавить/переделать "хорошие" хоткеи, они могут не понимать насколько это важно - это как пример.
В новых продуктах он не работает: сенсорный айфон
А это и не новый продукт с точки зрения интерфейса. Бумага с ручкой уже существовала. Брали бумагу, ставили на неё ручку/карандаш/фломастер и там, где есть касание, что-то происходит. В айфонах так же. В айфонах (условных) как раз более ожидаемый интерфейс, чем в кнопочных телефонах. Бумага и ручка тоже не на пустом месте имеют такой интерфейс - палочка и песочный пляж. Нет ничего более понятного, чем это. (deleted)
Но как тогда продуктовым командам показать, что они заняты чем-то полезным? :)
Сделать "улучшение", провести A/B тест, показать, что стало только хуже, и затем сразу же показать сколько стоило это всё сделать ("улучшение" и тесты) - необходимость что-то "делать" сразу же отпадёт. Если продукт действительно хорош. Что делать вместо этого? Хороший предприниматель всегда найдёт что - спросите у него.
Затем, со временем, это начнёт обрастать новыми функциями и "простота" перерастёт в "у нас есть 100 разделов, каждый из которых идеально быстро решает одну конкретную задачу", либо во что-то обычное.
"Сложность" современных интерфейсов не из-за "не умеют делать эргономично, не знают закон Фиттса (en), не думают об UX", не из-за жадности коммераснтов (хотя это тоже), но и из-за необходимости компактно уместить наиболее используемые разными когортами пользователей функции. "Идеальные" интерфейсы возможны только в очень специфичных условиях, для всех остальных есть принципы построения сложных интерфейсов, компромиссы, баланс, CustDev, A/B тесты, исследования и так далее.
Но т.к. люди не вечны и очень стереотипичны/"научены", то действительно самый главный и важный принцип - принцип наименьшего удивления. При смене пользователей на другой инструмент, пользователям должен быть предоставлен такой интферфейс с теми принципами дизайна, который им будет интуитивно понятен (то есть, уже знаком из опыта взаимодействия с другими интерфейсами). И речь не только про графический интерфейс, но и про хоткеи, про жесты мыши, про UX, про автосохранения, про отмену действий. Д даже цветовые решения ожидаются уже знакомые. В продолжение: руль, сенсорный экран, ручка двери, раскладной стакан, швейцарский нож - тоже примеры интерфейсов.
Новые привычки - очень сложно. Люди крайне неохотно идут на что-то новое. Людям (среднестатистическим, к нёрдам почти не применимо) проще жить на гроши на уже знакомой работе, чем пойти в соседний отдел на тройную ставку, т.к. соседний отдел - новое. Проще сидеть в абъюзивных отношениях, т.к. для них это привычно, они знают чего ожидать, но страх неизвестности нового и неизвестности усилий, чтобы это новое освоить, делает своё дело: люди продолжают есть кактусы, плеваться и жаловаться на это.
Я был сильно удивлён, что не обнаружил именно этот принцип в статье с таким кричащим заголовком.
Всё описанное мной не отменяет вашу статью, но лишь сдвигает её в приоритетах: помимо эффективности интерфейса как вещи в себе, должно быть ещё и эффективно переходить с предыдущих на этот. И если этот суммарный эффект меньше, чем при переходе на страшный неудобный, но привычный, то интерфейс, как бы это ни было печально озвучивать - неудачный. Опять же: этот абзац про краткосрочное взаимодействие с новыми интерфейсом. Если оно долгосрочное и нифига не разовое, то да, интерфейс должен быть эффективным. И этот принцип уже иногда может даже потеснить поистине главный (который я упоминял).
А ещё, по-хорошему, интерфейс сам по себе должен быть привычен самому себе же: если кто-то вдруг решит "обновить" интерфейс, уберя критически важное в нём - привычки - то новый интерфейс, каким бы классным ни был, всегда будет воспринят в штыки. И доказать, что новый лучше - сложная задача. С другой стороны, если людям не дают выбор, то они "жрут что дают" (если нет какой-то большей силы, которая могла бы это регулировать), но это отдельная тема...
Для тех, кто не понял, поясню. «Разы» не могут быть «до», «разы» могут быть только «в». Потому что это умножение. Мы умножаем во сколько-то раз. И уж никак не «до скольки-то раз». А почему бы им тогда не сказать правильно: «наши батарейки работают в 10 раз дольше, чем обычные батарейки»?
Потому что "обычные батарейки" это не один единственный тип одинаковых батареек с гарантированным сроком службы. "Обычные" батарейки могут служить разное время в разных условиях (физических) и разных режимах работы (в часах или в машинке на радиоуправлении). То есть для разных батареек есть диапазон времён службы. Для "необычных" батареек тоже есть диапазон. У вторых батареек он сдвинут дальше. А теперь следите за руками: первая категория батареек работает от 1 до 3 часов, вторая от 7 до 10. Итоговый результат: вторые батарейки работают от 2.3 до 10 раз дольше: 2.3 = минимальное время второго/максимальное время первого; 10 = максимальное время второго/минимальное время первого.
И, чтобы не нарушать закон о рекламе (нельзя обманывать), пишут, что работает не во сколько-то раз, а до стольки раз, т.к. "в 2 раза" вполне укладывается в "до 10 раз". Чтобы судов избежать.
Ну и да, если батарейка работает в неподходящих условиях, то вполне может прослужить меньше, чем "обычная", работающая в таких же условиях, но подходящих ей. Чтобы и в этом случае нельзя было судиться и указывают обтекаемые формулировки. Хотя про "неподходящие условия", обычно, есть отдельный пункт в инструкции.
И второе. Как мы понимаем, что вот этот камень именно с Марса?
Точно не знаю как это в общем случае, могу предположить: есть спектральное излучение материалов, которое в разных диапазонах различное для различных материалов. + по самому обломку можно примерно представить из каких процессов он мог "родиться", на объекте какого типа, в какое время (распад изотопов, накопление космической радиации). Сопоставляя все эти данные вместе, можно предположить с высокой долей вероятности откуда был тот или иной материал из космоса. Т.к. Марс относительно недалеко, его относительно легко было изучать, поэтому про него такие предположения могут быть более уверенные.
А в частном случае: с недавних пор у нас (у человечества) же на Марсе куча разных роверов гоняет, изучающих поверхность Марса. Телескопы в его сторону много смотрели, в т.ч. в разных диапазонах (тоже предположение). То есть у Землян есть понимание точного состава поверхности Марса и происходящих на нём процессов, из-за чего можно относительно точно распознать, что метеорит был именно с Марса.
Что-то мешает наносить тефлон поверх нанесённой плазмой подложки для закрепления PTFE? После бомбардирования плазмой создаются локальные перегретые участки, в т.ч. жидкие, из-за чего может образоваться сильная шероховатость. Чтобы не абразивы истирать, плазменное напыление используют, почему бы и нет? Это может быть выгоднее и проще в разработке конвейера. Хотя это нужно делать в специально подготовленной газовой среде (или вакуумной, если плазма служит материалом напыления, а не источником температуры).
Температура - это мера хаотичности движения и энергии этого самого движения. В лабораториях получают температуры и в миллионы градусов цельсия (лазером) - никто ж не возмущается, что это невозможно. Тут почему перевозбудились на статью?...
На постере не видно надписи, что сковороду нагревали до такой температуры. Написано "максимальная температура при производстве". Которая вполне могла быть у нагревающего поверхность плазменного или лазерного луча.
Может всем будет проще сразу делать и то и то просто правильно?
Давайте: "... а зачем сначала...", "... и то, и то..."
Где же наши твердые знаки на концах слов?
Сейчас вместо них пробелы (разделение слов). Твёрдые знаки нужны были для записи на бересте, чтобы экономить место (бересту сложно было делать): некоторые слова твёрдые знаки на конце не требовали, т.к. понятно как разделить слова, поэтому символов было меньше, чем если использовать пробелы. Затем этот же текст начали печатать в газетах, а там экономия была обратной - нужно было экономить чернила, поэтому стали вместо твёрдых знаков использовать пробелы (бумагу делать проще/выгоднее, чем чернила). В век компьютеров можно писать любые символы и любое их количество - электроны "дешёвые", экраны переиспользуемые.
...так исторически сложилось...
Первичны слова и звуки. Затем это нужно было как-то уместить в разумное кол-во букв. Разумное это сколько? Минимально возможное, чтобы не было путаницы что за слово при прочтении в контексте, но и чтобы произнести его можно было "правильно" (если знать правила), чтобы другие люди, знающие такие же "правила", могли его понять. Поэтому в разных языках в алфавитах сильно разное количество букв - там разная фонетика. И чем более сложнее фонетика и проще правила чтения, тем больше различных символов для записи слов (египетские иероглифы, китайский язык, японский язык).
Наоборот: английский язык - мало букв, сложные правила чтения, простая/короткая запись слов, уникальные смыслы задаются и уникальными словами, и сочетаниями слов (фразовые глаголы, залоги), порядок слов в предложении фиксирован;
немецкий язык - букв чуть больше, правила чтения проще некуда, запись слов и их чтение - затруднительны, много диграфов, триграфов и так далее, правила словообразования простые, уникальные смыслы часто задаются разным сочетанием слов (или составными словами), а не уникальными словами, порядок слов в предложении фиксирован.
Промежуточный вариант: русский язык - правила чтения несложные, букв относительно "много", правила словообразования сложные (очень много форм слов), правила сочетаний слов - сложные, уникальность смыслов передаётся в т.ч. сложными формами слов (иногда форм достаточно, неважно какие корни, мат поэтому так популярен, и поэтому же запрещён), неуникальные словоформы приобретают свой смысл в контексте, в правилах много исключений, порядок слов в предложении в общем случае неважен, иногда встречаются фразы, когда это влияет на смысл (при неизменности словоформ), ударения могут влять на значения слова.
Это намёк на возвращение старого дизайна ВК? Если да, то зачем им засорять ленту Хабра?
Если нет, то маловато для статьи: можно добавить примеры возврата к "старому", показать графики акций компаний после таких возвратов, объяснить какие функции выполняет такой шаг: оно, конечно, оригинально, но будет ли оно соответствовать духу времени, современным привычкам использования и современной скорости работы с информацией? Material UI он же (мои домыслы) про минимальное отвлечение от контента, чтобы мозг не перегружался информацией и человек мог больше времени посвятить контенту. Откат назад к "сложному" интерфейсу не скажется ли на ускорении возврата в реальности после листания ленты? Если скажется, как это скажется на рекламном бизнесе ВК?
С таким "возвратом", надеюсь, вернётся и простота реализации (технической, не визуальной) клиентской части: нынешняя реализация перегружена кодом и неприятно тормозит на железе средней давности.
Для пользы комментария, попрошу за себя и многих других (видел отзывы): сделайте нормальные ветки комменатриев - в современных ничего не найти. В идеале (моё мнение, про других не знаю), разделить (при чтении) комменатрии на, условно, "полезные", "смешные"/мемные и "эмоциональные", чтобы пользователи могли не читать не интересующий их мусор.
Ни одно всплывающее меню не похоже ни на какое другое: настройки профиля, аудио, настройки меню, настройки создания беседы, поиск, жалобы, просмотр инфы профиля. Там из общего наличие скрулгений и цвета. Какой-то единой задумки не чувствуется совсем. Даже одинаковые контекстные меню действий выглядят неодинаково: где-то hover во всю ширину прямоугольный и сверху-снизу есть рамочная полоска, а где-то hover не во всю ширину и скруглённый. То есть у них в каждом новом месте новая реализация. Что замедляет разработку и ухудшает поддерживаемость. Из-за чего разработка идёт медленно и дорого. Из-за чего могут не успевать думать о качестве, т.к. хотя бы тяп-ляп успеть бы сделать до релиза. Пример разных реализаций: кнопки закрытия просмотра постов стены/вложений переписки и кнопки закрытия просмотра фотографий: они по-разному реагируют на нажатия клавиш. То есть это независимо реализованные компоненты. Самописные. Как реагируют? Если нажать на первом типе кнопок ПКМ, то срабатывает клик ЛКМ. Если нажать на втором типе кнопок, то будет показано контекстное меню.
В каких-то попапах кнопка закрытия находится вне попапов, где-то внутри. Почему?
Выпадающие меню (select) тоже разные. Где-то квадратные с тёмным фоном hover, где-то обычные (со светлым hover), как в контекстных меню (которые с прямоугольниками. только тут без рамки снизу, как в контекстном).
Мобильная, десктоп и мобильная браузерная версии сильно различаются друг от друга. Притом мобильная браузерная самая ущербная (неужели ВК настолько жадные до данных и рекламного спама в пуше или мобильную версию так дорого поддерживать?).
Аватарки профиля и пабликов - та ещё история. В кажом разделе своя разметка (то есть везде разные реализации = дополнительная работа), свой набор стилей: список друзей, список в "избранном", список в "поставили лайк", в комментариях, в списке "друзья/подписчики этого профиля", в списке сообщений...
Некоторые элементы выглядит совсем инородными: плашка "New" напротив "добавить акаунт". Почему "New", а не "Новинка"? Почему вся эта кнопка непохожа ни на что из всего ВК? Почему они поменяли политику "никаких фейков и вторых страниц" на "добавляйте вторую страницу. Мы даже кнопку огромную сделали, чтобы вы не промазали"?
Про непохожесть раздела с видео на остальные уже упоминали. Это совсем кошмар.
P.S. Да, многие претензии выглядят как из анекдота про подсчёт спичек, понимаю. Но тут это влияет на скорость и качество разработки, на фокус внимания на реализации уже реализованного, а не на разработку нового функционала и улучшение UX.
Если вручную:
Теоретически и практически возможно (крючком, спицами сложнее, но тоже можно). Даже как минимум двумя способами.
Но удобство процесса и качество результата будет сомнительными.
От первой манжеты рукава по кругу;
потом туда-сюда всей высоте "тела", делая соответствующие изменения рядов для создания выреза под голову/шею; связать сначала, например, половину переда (под шеей), затем закрыть петли у шеи и перейти к вязке спины, обе половины под шеей, затем набрать доп петли (для компенсации закрытых и убавленных), довязать вторую половину переда, потом опять туда-сюда, затем нужно как-то аккуратно сшить бок, оставив петли для круговой вязки рукава;
дальше второй рукав и манжету.
Второй способ - то же самое, но "тело" вязать не прямыми рядами, а диагональными; так можно и шва бокового лишиться.
Но сразу скажу: никакой симметрии узора и эстетики в таком не будет, изначально так себе затея вязать всё одной деталью.
P.S. текст - личное мнение; если есть способы сделать свитер крутым одной деталью - с интересом прочитаю описание сего процесса.
В Windows всё ровно то же: чтобы заработало какое-то новое устройство, для него нужны драйверы, которых по умолчанию может не оказаться в системе.
Некоторые драйверы содержатся в ядре ОС, да.
Ядро ОС можно поставить новое из интерфейса, при включении устройства выбирать с каким ядром загружать систему. Если не понравится - можно удалить.
Часто про семейство дистрибутивов линукс говорят что-то, что справедливо и для Windows, только в Windows с этим реже сталкивались, т.к. ОС предустановлена = проверена для того железа, на котором установлена, вот и вся разница.
Мне несколько раз приходилось на винде обновлять драйверы для монитора и для каких-то устройств ввода (не помню) - то ещё развлечение; в linux это делается, обычно, одной командой, а не гуглежом на 20-30 минут и несколькими попытками "это оно или нет? всё уже?".
Похоже на то, что ядро старое было.
Новое железо поддерживается новыми ядрами ОС. Многие дистрибутивы (даже в новых версиях) используют какие-то древние (стабильные, проверенные) ядра.
Про зависание: предполагаю, проблема была связана либо с драйверами процессора (проприетарные нужно ставить самостоятельно), либо с драйверами кулера - новые в новом ядре.
С принтерами в Linux сталкивался только один раз - беспроводной большой МФУ. Из проблем: искать драйвер долго, но я его нашёл)
Но понимаю, что принтеров много, дистрибутивы разные и так далее.
На ручных вязальных машинах такие можно вязать.
Автоматически, в целом, тоже можно было бы вязать, думаю - тут только вопрос выгоды, не вижу особых сложностей.
Перчатки и варежки же вяжут автоматически - там тоже динамический размер рядов.
Я не об этом. Я про то, что бывает вязка как спицами и вязка как крючком.
В том, что вы описываете, вязка как спицами, как я понял.
Потому что вязка как крючком однозначно проигрывает по скорости вязкой как спицами, вряд ли там такая.
Полотна разные получаются в итоге.
И всё же хочется вязальную машинку, которая вязала бы "крючком". С точки зрения робототехники это более интересная задача. С точки зрения конечной продукции - тоже, т.к. крючком можно делать более сложные формы - игрушки, чехлы произвольной формы, более "воздушные" изделия ("спицами" получаются более замороченные и менее надёжные). Автоматических вязальных машин "спицами" уже существует большое кол-во. Вязальных машин крючком не встречал - это сильно удешевило бы процесс создания таких изделий (конечно, при условии, что амортизация стоимости такой машинки не перекроет всю выгоду от экономии на ручном труде).
Основная цель законопроекта - предприниматели, а не конечные пользователи.
Это нужно и чтобы рынок не штормило от постоянных колебаний "д вроде норм площадка" - "никогда больше сюда не приду, ухожу к другим" - "другие ещё хуже, буду продавать сам" - "д вроде норм маркетплейс был, что они там предлагают" - "какие же у них конские ценники и зверские условия, ухожу!" - ...;
и "защита прав индивидуальных предпринимателей" (де юре) - забрать самодеятельный произвол каждой из площадок и установить единые правила. Этой функцией (устанавливать такие правила), напоминаю, по самой идее государственности, обладает/должно обладать государство. Как они придумывают эти законы? Берут опыт у больших частных первопроходцев, которые поначалу придумывают правила сами и по ситуации их потом меняют. Когда правила настоялись и начинается произвол - вступает государство.
Почему с ОпСоСами не так? У них рынок поделён, не штормит, кому надо "дань" идёт за
монополиюхамское поведение с их стороны, основной "регулятор" ОпСоСов - ГРЧЦ - гос компания. Основные ОпСоСы (как и банки) "принадлежат" аффилированным с гос-вом компаниям (через ВТБ и ГазпромБанк как акционеров, через дружественных олигархов и их АФК "Система", "МеталлинвестБанк" и прочее).Озон и WB - условно "независимые" площадки. А ещё подобных площадок у кого только нет - ВК, Сбер, Яндекс, Авито, Юла, АлиЭкспресс, Амазон и так далее - их проще контролировать не договорняком, а более открытым и общим механизмом - законами.
Если про услуги в общем смысле, то общий механизм: на всё не хватает времени, денег и людей, готовых это исполнять, выставляют приоритеты. С начала 2022 сами понимаете какие приоритеты - удерживать устойчивость общества и страны; что не мешает активно вкладываться в инфраструктурные проекты (я лично это всё видел и был слегка в шоке от их кол-ва. Хотя качество в таком случае страдает, да).
Вы привели пример про "вам нужен костёр? Вам он не нужен, вот есть спички - тут тоже есть огонь" и я про это не писал - само собой опыт должен быть сопоставим с уровнем ответственности и компетенциями.
Но часто происходит "шашечки или ехать":
- мне нужен костёр, мне написали, что на костре можно разогреть еду.
- предлагаю вам газовую горелку, она безопаснее, сразу даёт тепло, сразу можно убрать огонь, если надо - одни плюсы!
- не, мне написали, что нужен костёр, притом на берёзовых поленьях. Про газовую горелку ничего не написано, поэтому "вы нам не подходите".
Хотя очевидно, что в этом примере нужна функция - разогреть еду. Тут и микроволновка могла подойти, и паровая баня и всё что угодно, выполняющее функцию.
Любой опытный Java программист, претендующий на программирование серверов на Go с описанием того, что он в экосистеме Go разбирается или может освоиться (в курсе из чего экосистема состоит), скорее всего понимает на что он идёт и, значит, нужно рассмотреть вариант дообучить его до нужной лёгкости владения инструментами экосистемы Go и провести техническое собеседование, а не послать его куда подальше, потому что "к сожалению, у вас недостаточно опыта программирования на Go, а менеджеру это очень нужно". И неважно, если этот разработчик очень хорош в программировании серверных микросервисов/модулей, особенно многопоточных и без гонки данных.
Гораздо ценнее разработчик, который на практике владеет методами предотвращения гонки данных в любых системах (в которых они теоретически возможны), чем разработчик, подходящий под описание "имеет опыт работы на Go не меньше двух лет". Но поди объясни это менеджеру или HR'ам...
Стереотипы, шаблонность, уравниловка. Вы ищете идеально подходящего кандидата по какому-то не обязательно идеальному описанию или того, кто будет работать?
Не те курсы, видимо, проходите. Программирование серверов, сайтов и игр, в сущности своей, имеет сильно больше общего, чем различий.
Программирование из написания кода на каком-то языке состоит процентов на 15-20. С хорошими ТЗ и тестировщиками может процентов на 30-40. Всё остальное время - обсуждение задач, проектирование логики, обсуждение требований, тестирование, дебаггинг (он на всех языках одного класса (императивные, например) одинаковый. Мне, помнится, приходилось дебажить код на С++, когда я его ещё не знал (знал Java7), исправил исходный код, перекомпилировал и запустил в работу платформу, на которой в итоге работал с целевым ЯП (не C++)), описание багов, приоритезация задач (у кого побольше опыта), системный анализ (который уже не может делать аналитик из-за технических тонкостей), оптимизация алгоритмов/процессов (это вообще общеинженерный навык, не только айтишный), проведение экспериментов и продуктовых тестов (профиль нагрузки, latency, отказоустойчивость), написание первичной документации.
И даже писанина на каком-то языке или на какой-то платформе состоит не из знания перечня всех возможных функций и их аргументов на этой технологии, а из общего знания "что должно быть, как это должно работать, в теории". Любой опытный айтишник запросто сменит свою проф. область за месяц-полтора-два при должной мотивации.
Но HR рынок по-прежнему продолжают искать по принципу:
Стаж работы? За 1 год интенсивной R&D работы можно изучить раз в 10 больше, чем за 5 лет поддержки готового legacy кода. Неужели менеджеры в IT этого не понимают? Сомневаюсь.
Все люди разные. Некоторые способны программировать на технологиях, которые впервые в жизни видят, а некоторые с уже хорошо знакомыми технологиями чуть в сторону отойти не могут - "этим всегда DevOps/тестировщик/аналитик/архитектор занимался, я не знаю ничего оттуда".
Но "стаж", "опыт", "проекты"...
Нет! Называйте вещи своими именами: это чеклист, который позволяет HR проще отсеивать тех, кто не подходит под ваши шаблоны. Для кандидатов такие рекомендации не помогают!
У меня есть два резюме: в одном я соблюдал все возможные рекомендации - более "образцового" резюме не найти. На 140+ моих откликов штук 70 молчаливых отказов, около 40 просто тупо игноров, штук 30 опросов от HR, технических собеседований штук 15. Офферов 3-4. Приглашений от HR штук 5 за 4+ месяцев поиска.
Во втором резюме указаны всё те же самые навыки, нет фото, нет описания деятельности в компании, нет описания моих достижений, нет даже ФИО. Это резюме нарушает все возможные рекомендации, кроме одной: указывать свои навыки, которыми я уже владею или способен быстро освоить. Какой результат? 7 приглашений от крупных работадателей за 2 дня. После созвонов (на которых я старался давать минимально возможную и максимально общую информацию, никакого упоминания негатива про кого бы то ни было, даже если его было очень много) технических собеседований из них назначено некоторое кол-во. Сам ещё ни разу не откликался этим резюме.
Так кому вы помогаете своими советами?
И тимлиды ещё "молодцы": отсекают по каждой шероховатости, не стремятся вычленить толковых, стараются найти идеально подходящего под свои шаблоны видения кандидатов (которое тоже не всегда идеально). Даже по тем знаниям, которые гуглятся за 1 минуту и после двух-трех употребление в использовании запоминаются на долгие годы.
Может эти статьи по найму лучше не самим усваивать, а стараться научить тимлидов нанимать?
За все технические интервью, действительно толковые собеседователи попадались 2 раза. Многие из остальных - опытные нёрды с дутым ЧСВ, либо следующие формальным принакам отбора, которые они составляли как? Методологию проверки знаний тимлиды вряд ли изучают - им же некогда, они же и работают, ещё и уровень кандидатов определять. Особенно, когда нужно вытягивать из кандидатов информацию (а из айтишников надо, коммуникабельных нечасто видел).
И вишенка на торте: тимлиды не учитывают человеческий фактор. Люди - существа эмоциональные и эмоциональное состояние сильно влияет на степень воспроизводства той или иной информации. А ещё частое напряжение памяти и формулирование новых мыслей - очень утомительно. В итоге из-за волнения и перенапряжения человек через 5-10 минут расклеивается, начинает путаться в терминологии, забывает что-то (хотя минут через 10 после завершения с лёгкостью это вспомнит), начинает плохо соображать и всё такое. В итоге может выглядеть (не являться) неопытным, хотя может быть как раз идеально подходящим на роль техлида или ведущего разработчика.
Недавно на технческом интервью через 15 минут после начала переволновался, встал в ступор, в голове пропали все мысли и не смог написать простой SQL запрос, хотя вот только что написал уже несколько не проще этого и полностью назвал алгоритм, как надо его составлять. В итоге тимлид отказал в найме. Через 5 минут после завершения собеса проверил озвученный мной алгоритм - он правильный.
Ещё: есть люди соображающие быстро, а есть, у кого мысли должны повариться и хороший ответ приходит сильно потом. Я из вторых. И в моменте сильно теряюсь, такая вот специфика организма. Из-за этого заваливал многие интервью только потому что не смог сказать синонимичное слово к уже озвученному, а тимлид ожидал услышать именно его.
Рынок IT найма сломан (если хоть когда-то был работающим). И как его чинить/выстраивать - пока непонятно.
Зря я, видимо, перепутал фразу "потоки процессора" и "потоки ОС". И там, и там они называются threads и упомянул пример неаккуратно, да.
Историю выбора слова thread действительно не знал (в работе не пригождалось, акцентов на историю никогда не расставлял, с недавних пор исправляюсь), спасибо за интересную и поучительную историю.
Но всё ещё продолжу утверждать, что слово "thread" как название чего-то "проактивно" действующего (если смотреть со стороны данных в программе) - плохой выбор, т.к. слово thread отображает объект (нитку) и действия, с ним связанные (накручивать и так далее). "Адаптивный перевод" на русский язык чуть более удачный (более физичен и естественен), но создаёт путаницу в уже существующих терминах и не слишком специфично, что можно видеть во всяких шутках типа "управление потока потока разделено на два потока" = "control flow of stream is split between two threads" (подобные конструкции на работе встречались часто, приходилось каждый раз выдумывать как это разделять - это очень неудобно).
Я в курсе (не сильно), что поток/thread (в ОС) это лишь набор инструкций, постоянных и переменных данных, а не исполнитель как вещь в себе, и что фактическую работу ведут процессоры (напару с инструкциями ОС) и генераторы частот.
@shasoftXрассуждал "зачем вводить новые однозначно понятные термины, как их потом обратно переводить и понимать о чём речь?", на что можно парировать: слово поток (как thread) почему-то же уже устраивает, хотя нет таких вариантов обратного "перевода" при переводе на англ.
И дальше @gBear пишет
А потом пользуйся этим через 20 лет, ага.
Уверен, если собраться представителями индустрии, которая производит БД и переводчиками и договориться о терминах всем вместе, то это будет всем на пользу. Да и на другие страны такую практику тоже можно будет перекинуть, если хорошо пойдёт.
Master и blacklist переименовали же в main и blocklist всем скопом.
Хотя есть шанс, что где-то останутся "консерваторы" движения "так исторически сложилось" и будут радикально отстаивать, как со словами Ройтерс (Reuters, по ошибке "Рейтер"), Фройд (Freud, "Фрейд") и Айнштайн (Einstein, "Эйнштейн").
Как в таком окружении будешь исправлять свои ошибки, если всё вокруг орёт "да, была ошибка, но все к ней уже привыкли, не надо ничего менять"? Хотя даже Microsoft исправила свою давнюю ошибку.
Именно поэтому я написал "процессоров". У нескольких процессоров может же суммарно быть больше двух потоков?
Изначальный перевод слова "thread" не очень удачный просто. А дальше уже "исторически сложилось". Да и сам термин "thread" неудачный. Он же буквально переводится "нить"/"нитка".
Вообще, у слова "thread" есть такие переводы, которые выглядят более-менее естественно и на русском языке. Например, "жила".
"Для обработки такого потока требуется 10 жил процессоров".
Вообще, раз изначально выбран странный термин, то можно не переводить или адаптировать термин, а изобрести свой, отображающий суть явления, но такой, чтобы неоднозначностей быть не могло.
Thread в IT это какой-то трудяга в рамках ОС, но при этом ОС целостная, всем "потокам" достаётся какое-то время процессоров, но фактическими исполнителями (управляющими конструкциями + хранителями стека, кучи и инструкций) являются как раз "потоки".
Есть что-то похожее в природе? Ульи! Как тогда можно было бы назвать "потоки"? "Трутень"/"трутни".
"Для обработки этого потока требуется 10 трутней". Вполне звучит, неоднозначностей никаких.
По аналогии можно было бы что-то придумать для различия flow (поток-явление) и stream (поток-процесс).
Исследователи исследуют ЦА, не самих себя. Если продукт широкого профиля и заточен на общечеловеческие принципы (не на какую-то специальность), то согласен, что так можно много гипотез получить из первых принципов, но исследования нужны для анализа другого профиля пользователей, для других информационных пузырей и так далее. Есть люди, которые никогда не играли в шутеры или MOBA и для них может быть совершенно непонятно требование пользователей добавить/переделать "хорошие" хоткеи, они могут не понимать насколько это важно - это как пример.
А это и не новый продукт с точки зрения интерфейса. Бумага с ручкой уже существовала. Брали бумагу, ставили на неё ручку/карандаш/фломастер и там, где есть касание, что-то происходит. В айфонах так же. В айфонах (условных) как раз более ожидаемый интерфейс, чем в кнопочных телефонах.
Бумага и ручка тоже не на пустом месте имеют такой интерфейс - палочка и песочный пляж. Нет ничего более понятного, чем это.
(deleted)
Сделать "улучшение", провести A/B тест, показать, что стало только хуже, и затем сразу же показать сколько стоило это всё сделать ("улучшение" и тесты) - необходимость что-то "делать" сразу же отпадёт. Если продукт действительно хорош.
Что делать вместо этого? Хороший предприниматель всегда найдёт что - спросите у него.
Затем, со временем, это начнёт обрастать новыми функциями и "простота" перерастёт в "у нас есть 100 разделов, каждый из которых идеально быстро решает одну конкретную задачу", либо во что-то обычное.
"Сложность" современных интерфейсов не из-за "не умеют делать эргономично, не знают закон Фиттса (en), не думают об UX", не из-за жадности коммераснтов (хотя это тоже), но и из-за необходимости компактно уместить наиболее используемые разными когортами пользователей функции. "Идеальные" интерфейсы возможны только в очень специфичных условиях, для всех остальных есть принципы построения сложных интерфейсов, компромиссы, баланс, CustDev, A/B тесты, исследования и так далее.
Но т.к. люди не вечны и очень стереотипичны/"научены", то действительно самый главный и важный принцип - принцип наименьшего удивления. При смене пользователей на другой инструмент, пользователям должен быть предоставлен такой интферфейс с теми принципами дизайна, который им будет интуитивно понятен (то есть, уже знаком из опыта взаимодействия с другими интерфейсами). И речь не только про графический интерфейс, но и про хоткеи, про жесты мыши, про UX, про автосохранения, про отмену действий. Д даже цветовые решения ожидаются уже знакомые. В продолжение: руль, сенсорный экран, ручка двери, раскладной стакан, швейцарский нож - тоже примеры интерфейсов.
Новые привычки - очень сложно. Люди крайне неохотно идут на что-то новое. Людям (среднестатистическим, к нёрдам почти не применимо) проще жить на гроши на уже знакомой работе, чем пойти в соседний отдел на тройную ставку, т.к. соседний отдел - новое. Проще сидеть в абъюзивных отношениях, т.к. для них это привычно, они знают чего ожидать, но страх неизвестности нового и неизвестности усилий, чтобы это новое освоить, делает своё дело: люди продолжают есть кактусы, плеваться и жаловаться на это.
Я был сильно удивлён, что не обнаружил именно этот принцип в статье с таким кричащим заголовком.
Всё описанное мной не отменяет вашу статью, но лишь сдвигает её в приоритетах: помимо эффективности интерфейса как вещи в себе, должно быть ещё и эффективно переходить с предыдущих на этот. И если этот суммарный эффект меньше, чем при переходе на страшный неудобный, но привычный, то интерфейс, как бы это ни было печально озвучивать - неудачный.
Опять же: этот абзац про краткосрочное взаимодействие с новыми интерфейсом. Если оно долгосрочное и нифига не разовое, то да, интерфейс должен быть эффективным. И этот принцип уже иногда может даже потеснить поистине главный (который я упоминял).
А ещё, по-хорошему, интерфейс сам по себе должен быть привычен самому себе же: если кто-то вдруг решит "обновить" интерфейс, уберя критически важное в нём - привычки - то новый интерфейс, каким бы классным ни был, всегда будет воспринят в штыки. И доказать, что новый лучше - сложная задача.
С другой стороны, если людям не дают выбор, то они "жрут что дают" (если нет какой-то большей силы, которая могла бы это регулировать), но это отдельная тема...
Потому что "обычные батарейки" это не один единственный тип одинаковых батареек с гарантированным сроком службы.
"Обычные" батарейки могут служить разное время в разных условиях (физических) и разных режимах работы (в часах или в машинке на радиоуправлении). То есть для разных батареек есть диапазон времён службы.
Для "необычных" батареек тоже есть диапазон. У вторых батареек он сдвинут дальше.
А теперь следите за руками: первая категория батареек работает от 1 до 3 часов, вторая от 7 до 10. Итоговый результат: вторые батарейки работают от 2.3 до 10 раз дольше: 2.3 = минимальное время второго/максимальное время первого; 10 = максимальное время второго/минимальное время первого.
И, чтобы не нарушать закон о рекламе (нельзя обманывать), пишут, что работает не во сколько-то раз, а до стольки раз, т.к. "в 2 раза" вполне укладывается в "до 10 раз". Чтобы судов избежать.
Ну и да, если батарейка работает в неподходящих условиях, то вполне может прослужить меньше, чем "обычная", работающая в таких же условиях, но подходящих ей. Чтобы и в этом случае нельзя было судиться и указывают обтекаемые формулировки. Хотя про "неподходящие условия", обычно, есть отдельный пункт в инструкции.
Точно не знаю как это в общем случае, могу предположить: есть спектральное излучение материалов, которое в разных диапазонах различное для различных материалов. + по самому обломку можно примерно представить из каких процессов он мог "родиться", на объекте какого типа, в какое время (распад изотопов, накопление космической радиации).
Сопоставляя все эти данные вместе, можно предположить с высокой долей вероятности откуда был тот или иной материал из космоса.
Т.к. Марс относительно недалеко, его относительно легко было изучать, поэтому про него такие предположения могут быть более уверенные.
А в частном случае: с недавних пор у нас (у человечества) же на Марсе куча разных роверов гоняет, изучающих поверхность Марса. Телескопы в его сторону много смотрели, в т.ч. в разных диапазонах (тоже предположение). То есть у Землян есть понимание точного состава поверхности Марса и происходящих на нём процессов, из-за чего можно относительно точно распознать, что метеорит был именно с Марса.
Что-то мешает наносить тефлон поверх нанесённой плазмой подложки для закрепления PTFE? После бомбардирования плазмой создаются локальные перегретые участки, в т.ч. жидкие, из-за чего может образоваться сильная шероховатость. Чтобы не абразивы истирать, плазменное напыление используют, почему бы и нет? Это может быть выгоднее и проще в разработке конвейера. Хотя это нужно делать в специально подготовленной газовой среде (или вакуумной, если плазма служит материалом напыления, а не источником температуры).
Температура - это мера хаотичности движения и энергии этого самого движения. В лабораториях получают температуры и в миллионы градусов цельсия (лазером) - никто ж не возмущается, что это невозможно. Тут почему перевозбудились на статью?...
На постере не видно надписи, что сковороду нагревали до такой температуры. Написано "максимальная температура при производстве". Которая вполне могла быть у нагревающего поверхность плазменного или лазерного луча.
Давайте:
"... а зачем сначала...", "... и то, и то..."
Сейчас вместо них пробелы (разделение слов). Твёрдые знаки нужны были для записи на бересте, чтобы экономить место (бересту сложно было делать): некоторые слова твёрдые знаки на конце не требовали, т.к. понятно как разделить слова, поэтому символов было меньше, чем если использовать пробелы. Затем этот же текст начали печатать в газетах, а там экономия была обратной - нужно было экономить чернила, поэтому стали вместо твёрдых знаков использовать пробелы (бумагу делать проще/выгоднее, чем чернила).
В век компьютеров можно писать любые символы и любое их количество - электроны "дешёвые", экраны переиспользуемые.
Первичны слова и звуки. Затем это нужно было как-то уместить в разумное кол-во букв. Разумное это сколько? Минимально возможное, чтобы не было путаницы что за слово при прочтении в контексте, но и чтобы произнести его можно было "правильно" (если знать правила), чтобы другие люди, знающие такие же "правила", могли его понять.
Поэтому в разных языках в алфавитах сильно разное количество букв - там разная фонетика. И чем более сложнее фонетика и проще правила чтения, тем больше различных символов для записи слов (египетские иероглифы, китайский язык, японский язык).
Наоборот: английский язык - мало букв, сложные правила чтения, простая/короткая запись слов, уникальные смыслы задаются и уникальными словами, и сочетаниями слов (фразовые глаголы, залоги), порядок слов в предложении фиксирован;
немецкий язык - букв чуть больше, правила чтения проще некуда, запись слов и их чтение - затруднительны, много диграфов, триграфов и так далее, правила словообразования простые, уникальные смыслы часто задаются разным сочетанием слов (или составными словами), а не уникальными словами, порядок слов в предложении фиксирован.
Промежуточный вариант: русский язык - правила чтения несложные, букв относительно "много", правила словообразования сложные (очень много форм слов), правила сочетаний слов - сложные, уникальность смыслов передаётся в т.ч. сложными формами слов (иногда форм достаточно, неважно какие корни, мат поэтому так популярен, и поэтому же запрещён), неуникальные словоформы приобретают свой смысл в контексте, в правилах много исключений, порядок слов в предложении в общем случае неважен, иногда встречаются фразы, когда это влияет на смысл (при неизменности словоформ), ударения могут влять на значения слова.
Это намёк на возвращение старого дизайна ВК? Если да, то зачем им засорять ленту Хабра?
Если нет, то маловато для статьи: можно добавить примеры возврата к "старому", показать графики акций компаний после таких возвратов, объяснить какие функции выполняет такой шаг: оно, конечно, оригинально, но будет ли оно соответствовать духу времени, современным привычкам использования и современной скорости работы с информацией?
Material UI он же (мои домыслы) про минимальное отвлечение от контента, чтобы мозг не перегружался информацией и человек мог больше времени посвятить контенту. Откат назад к "сложному" интерфейсу не скажется ли на ускорении возврата в реальности после листания ленты? Если скажется, как это скажется на рекламном бизнесе ВК?
С таким "возвратом", надеюсь, вернётся и простота реализации (технической, не визуальной) клиентской части: нынешняя реализация перегружена кодом и неприятно тормозит на железе средней давности.
Для пользы комментария, попрошу за себя и многих других (видел отзывы): сделайте нормальные ветки комменатриев - в современных ничего не найти. В идеале (моё мнение, про других не знаю), разделить (при чтении) комменатрии на, условно, "полезные", "смешные"/мемные и "эмоциональные", чтобы пользователи могли не читать не интересующий их мусор.
Ни одно всплывающее меню не похоже ни на какое другое: настройки профиля, аудио, настройки меню, настройки создания беседы, поиск, жалобы, просмотр инфы профиля. Там из общего наличие скрулгений и цвета. Какой-то единой задумки не чувствуется совсем.
Даже одинаковые контекстные меню действий выглядят неодинаково: где-то hover во всю ширину прямоугольный и сверху-снизу есть рамочная полоска, а где-то hover не во всю ширину и скруглённый. То есть у них в каждом новом месте новая реализация. Что замедляет разработку и ухудшает поддерживаемость. Из-за чего разработка идёт медленно и дорого. Из-за чего могут не успевать думать о качестве, т.к. хотя бы тяп-ляп успеть бы сделать до релиза.
Пример разных реализаций: кнопки закрытия просмотра постов стены/вложений переписки и кнопки закрытия просмотра фотографий: они по-разному реагируют на нажатия клавиш. То есть это независимо реализованные компоненты. Самописные. Как реагируют? Если нажать на первом типе кнопок ПКМ, то срабатывает клик ЛКМ. Если нажать на втором типе кнопок, то будет показано контекстное меню.
В каких-то попапах кнопка закрытия находится вне попапов, где-то внутри. Почему?
Выпадающие меню (select) тоже разные. Где-то квадратные с тёмным фоном hover, где-то обычные (со светлым hover), как в контекстных меню (которые с прямоугольниками. только тут без рамки снизу, как в контекстном).
Мобильная, десктоп и мобильная браузерная версии сильно различаются друг от друга. Притом мобильная браузерная самая ущербная (неужели ВК настолько жадные до данных и рекламного спама в пуше или мобильную версию так дорого поддерживать?).
Аватарки профиля и пабликов - та ещё история. В кажом разделе своя разметка (то есть везде разные реализации = дополнительная работа), свой набор стилей: список друзей, список в "избранном", список в "поставили лайк", в комментариях, в списке "друзья/подписчики этого профиля", в списке сообщений...
Некоторые элементы выглядит совсем инородными: плашка "New" напротив "добавить акаунт". Почему "New", а не "Новинка"? Почему вся эта кнопка непохожа ни на что из всего ВК? Почему они поменяли политику "никаких фейков и вторых страниц" на "добавляйте вторую страницу. Мы даже кнопку огромную сделали, чтобы вы не промазали"?
Про непохожесть раздела с видео на остальные уже упоминали. Это совсем кошмар.
P.S. Да, многие претензии выглядят как из анекдота про подсчёт спичек, понимаю. Но тут это влияет на скорость и качество разработки, на фокус внимания на реализации уже реализованного, а не на разработку нового функционала и улучшение UX.