Перевёл бы именно так: все тексты блога SkillFactory на Хабре проходят через меня, я отбираю тексты на перевод, поэтому могу давать столь подробные ответы.
Второй вопрос очень провокационный. :) потому, что, если говорить об абсолютно всех нюансах, то учесть и отразить их все невозможно по самой природе языков и переводов.
У языков свои ритмы, у слов — своя история, уникальные пропорции нагруженности смыслами и оттенками, особые отношения внутри общества носителей, которые в разных языках не могут совпадать один-в-один. Чем-то всегда приходится жертвовать. Здесь, например, в жертву принесён оттенок "симпатичности" neat.
Поэтому вернее говорить не о безошибочном переводе всех тонкостей, который невозможен, а о задачах текста, конечной цели коммуникации. Ошибки, к сожалению, тоже случаются. Текст — это прежде всего работа психики, которая совсем не резиновая, согласен с вами. А иные тексты вообще требуют консультаций с автором оригинала.
Например, когда человек на природе, у родника, потерял ключ от чего-нибудь, а в самом конце — без контекста — написано, что он нашёл ключ. Как это переводить переводчику с русского на английский, если он не знает, что хотел сказать автор, а текст на это не указывает целенаправленно?
Но я ушёл в сторону; за точность терминов и прочую техническую часть также отвечаю я. Поэтому, если вопрос касается именно этого текста, то он сам — ответ на ваш вопрос. :)
Не совсем понял, о чём вы хотите сказать. Конечно, квалифицированный специалист, которого трудно уволить, как минимум, из-за квалификации, найдёт работу быстрее других, у него самые широкие возможности. Отсюда в крайнем случае выше имеем большую вероятность, что те самые 10 нужных математиков просто не вышли на рынок с резюме, потому что уже заняты. А проблема востребованности остаётся.
Большое количество резюме само по себе не решает проблему востребованности и нехватки, и даже может ещё сильнее обострить её. Возьмём крайний случай: вы хотите создать принципиально новую криптовалюту и вам нужны очень квалифицированные программисты-математики, вы создаёте востребованность в этих специалистах, но их, например, десятки, а резюме на рынке десятки тысяч. Почему я говорю "обострить"? Потому, что, пока вы перебираете резюме и собеседуете кандидатов, идёт время, а задача не решается.
Пример проще и ближе к программированию: по-разному решающих одну и ту же проблему библиотек и инструментов может быть очень много, и чем их больше, тем сложнее выбрать библиотеку, подходящую именно вам, под детали ваших задач.
С другой стороны, если библиотеки нет вообще, это не значит, что она вам не нужна (не востребована вами), как в случае с упавшей конкуренцией в сфере ИИ.
В итоге идеальная ситуация на рынке — это когда есть баланс в количестве и разнообразии кандидатов и работодателей. Но эта ситуация, конечно, именно идеальная. Где-то будут перекосы, о них мы и пишем.
Согласен с вами — в узком смысле слов "качество кода" оно определяется принятыми стандартами кодирования, тем, какие правила линтера отрабатывают перед коммитом, насколько разработчик следит за техдолгом, пользуется ли статическим анализом, избегает ли копипасты, понятно ли именует переменные и т. д.
Но в широком смысле можно ли назвать качественным код, который не соответствует требованиям, просто не делает того, что должен делать? Даже ручной тестировщик в итоге вкладывается в качество кода и следит именно за ним, потому что, в конечном счёте, по его баг-репортам именно код становится лучше, качественнее в конкретных местах. И видно, где опечатка (пренебрежение статическим анализом), где упущенный if или ещё что-нибудь.
Если в пакет с надписью «солёные фисташки» положили сладкий арахис, то, купив такие "фисташки", скорее всего, вы сделаете вывод о качестве всех продуктов производителя. Поэтому соответствие требованиям — один из ключевых показателей качества.
Во всей статье речь идёт о точности работы Ghidra, которая далее подчёркивается сравнением с другими инструментами.
Для контрольной суммы важна именно точность: если бы Ghidra отработала неточно (как поначалу со строками), то из-за CRC после переупаковки система не загрузилась бы, о чём и пишет автор.
Если заглянуть, например, в словарь Мюллера, о neat увидим: "4) я́сный, то́чный; лакони́чный; отто́ченный (о стиле, языкеи т.п.)"
Ясной, лаконичной, а значит и точной эту контрольную сумму назвать точно можно, но симпатичной — это уже дело вкуса. Мне она симпатичной не кажется.
Вариант "Не узнают" затрудняет чтение текста лишним мысленным усилием: нужно разбираться, куда ставить ударение и проверять его правильность, произнести мысленно слово с таким ударением труднее. А просто не видят (не распознают, а значит, и не узнают) звучит проще, естественнее; повтор отражает интонацию увлечённости.
Очень понравилось, как МойОфис отображает шрифты, даже захотелось переехать насовсем с Google Doc. MacType'ом сыт не будешь. Спасибо. Но для работы пока интерфейс небогатый и не очень продуманный: например, Ctrl+K не работает с выделенным текстом. Очень жду обновлений интерфейса.
Ну и с лицензиями не совсем понятно сразу, могу ли я бесплатную версию использовать в коммерческих целях.
The truth is that while we rely on the Chromium engine to render the pages correctly, this is where similarities with Chrome (and other Chromium-based browsers) end.
Короче говоря, Хромиум только рендерит страницы. Не всё так плохо.
Насколько я понимаю, под минимизацией корпуса автор имеет в виду технику, когда программа тестирования сокращает количество входных данных, ориентируясь на сам код. Минимизация по определению направлена на сокращение чего-либо, поэтому программу не интересуют надмножества, расширенные наборы и т.п., она сделана так, чтобы обращать внимание на подмножества, затачивая подаваемые данные под них.
То есть руками вы, конечно, придумаете нужную комбинацию, а вот автоматы эту штуку упустят из-за оптимизаций. Как у Кнута: «Преждевременная оптимизация — корень всех зол». Думаю, «никогда» — это преувеличение, чтобы обратить внимание на проблему. Иначе бы автор сам ничего не нашёл.
В go автоформат даже из коробки; но там сам язык располагает, а у Python, скорее всего, дело в смысле отступов — подход нужен аккуратный, поэтому автоформат пишется долго и трудно. Ждём. И может быть поможет: список отобранных форматтеров.
Согласен. Но в разработке ситуация, видимо, стала лучше:
По словам гендиректора «Мегаплана» Сергея Козлова, раньше в Москву перетекали разработчики из регионов, но теперь они «ленятся переезжать и предпочитают работать удалённо из своего города за московские зарплаты».
Пока что эта программа заменяется зрелыми клиентами, например QuiteRSS, но чувствуется, что QRSS может умереть в плане поддержки. RSSOwl — на Java. Но там не хватает адекватной чистки новостей.
Прочие клиенты страшно тяжёлые и не заточены под условного технаря, которому нужно полноценное информационное поле, а здесь есть этот потенциал после множества переосмыслений. Третьи вообще совсем мелкие поделки, четвёртые — веб, что далеко не всегда удобно. И т. д.
Короче говоря — не останавливайтесь. Буду рад лет через несколько увидеть клиент с хорошо заточенными фильтрами и аккуратной работой именно с поиском. Такие штуки востребованы среди тех, кто плотно работает с новостями.
Вы правы, но имеете в виду другое лидерство: в 2007, 2010, 2018 и 2020 Python был языком года, то есть его популярность росла быстрее популярности других языков, но Python ещё не был самым популярным.
Поправили, большое спасибо!
Перевёл бы именно так: все тексты блога SkillFactory на Хабре проходят через меня, я отбираю тексты на перевод, поэтому могу давать столь подробные ответы.
Второй вопрос очень провокационный. :) потому, что, если говорить об абсолютно всех нюансах, то учесть и отразить их все невозможно по самой природе языков и переводов.
У языков свои ритмы, у слов — своя история, уникальные пропорции нагруженности смыслами и оттенками, особые отношения внутри общества носителей, которые в разных языках не могут совпадать один-в-один. Чем-то всегда приходится жертвовать. Здесь, например, в жертву принесён оттенок "симпатичности" neat.
Поэтому вернее говорить не о безошибочном переводе всех тонкостей, который невозможен, а о задачах текста, конечной цели коммуникации. Ошибки, к сожалению, тоже случаются. Текст — это прежде всего работа психики, которая совсем не резиновая, согласен с вами. А иные тексты вообще требуют консультаций с автором оригинала.
Например, когда человек на природе, у родника, потерял ключ от чего-нибудь, а в самом конце — без контекста — написано, что он нашёл ключ. Как это переводить переводчику с русского на английский, если он не знает, что хотел сказать автор, а текст на это не указывает целенаправленно?
Но я ушёл в сторону; за точность терминов и прочую техническую часть также отвечаю я. Поэтому, если вопрос касается именно этого текста, то он сам — ответ на ваш вопрос. :)
Не совсем понял, о чём вы хотите сказать. Конечно, квалифицированный специалист, которого трудно уволить, как минимум, из-за квалификации, найдёт работу быстрее других, у него самые широкие возможности. Отсюда в крайнем случае выше имеем большую вероятность, что те самые 10 нужных математиков просто не вышли на рынок с резюме, потому что уже заняты. А проблема востребованности остаётся.
Большое количество резюме само по себе не решает проблему востребованности и нехватки, и даже может ещё сильнее обострить её. Возьмём крайний случай: вы хотите создать принципиально новую криптовалюту и вам нужны очень квалифицированные программисты-математики, вы создаёте востребованность в этих специалистах, но их, например, десятки, а резюме на рынке десятки тысяч. Почему я говорю "обострить"? Потому, что, пока вы перебираете резюме и собеседуете кандидатов, идёт время, а задача не решается.
Пример проще и ближе к программированию: по-разному решающих одну и ту же проблему библиотек и инструментов может быть очень много, и чем их больше, тем сложнее выбрать библиотеку, подходящую именно вам, под детали ваших задач.
С другой стороны, если библиотеки нет вообще, это не значит, что она вам не нужна (не востребована вами), как в случае с упавшей конкуренцией в сфере ИИ.
В итоге идеальная ситуация на рынке — это когда есть баланс в количестве и разнообразии кандидатов и работодателей. Но эта ситуация, конечно, именно идеальная. Где-то будут перекосы, о них мы и пишем.
Согласен с вами — в узком смысле слов "качество кода" оно определяется принятыми стандартами кодирования, тем, какие правила линтера отрабатывают перед коммитом, насколько разработчик следит за техдолгом, пользуется ли статическим анализом, избегает ли копипасты, понятно ли именует переменные и т. д.
Но в широком смысле можно ли назвать качественным код, который не соответствует требованиям, просто не делает того, что должен делать? Даже ручной тестировщик в итоге вкладывается в качество кода и следит именно за ним, потому что, в конечном счёте, по его баг-репортам именно код становится лучше, качественнее в конкретных местах. И видно, где опечатка (пренебрежение статическим анализом), где упущенный if или ещё что-нибудь.
Если в пакет с надписью «солёные фисташки» положили сладкий арахис, то, купив такие "фисташки", скорее всего, вы сделаете вывод о качестве всех продуктов производителя. Поэтому соответствие требованиям — один из ключевых показателей качества.
На самом деле нюансы учтены, но другие:
Во всей статье речь идёт о точности работы Ghidra, которая далее подчёркивается сравнением с другими инструментами.
Для контрольной суммы важна именно точность: если бы Ghidra отработала неточно (как поначалу со строками), то из-за CRC после переупаковки система не загрузилась бы, о чём и пишет автор.
Если заглянуть, например, в словарь Мюллера, о neat увидим: "4) я́сный, то́чный; лакони́чный; отто́ченный (о стиле, языке и т.п.)"
Ясной, лаконичной, а значит и точной эту контрольную сумму назвать точно можно, но симпатичной — это уже дело вкуса. Мне она симпатичной не кажется.
Вариант "Не узнают" затрудняет чтение текста лишним мысленным усилием: нужно разбираться, куда ставить ударение и проверять его правильность, произнести мысленно слово с таким ударением труднее. А просто не видят (не распознают, а значит, и не узнают) звучит проще, естественнее; повтор отражает интонацию увлечённости.
Конечно, второе полугодие 2021 :) самые свежие данные. Спасибо, поправили
Очень понравилось, как МойОфис отображает шрифты, даже захотелось переехать насовсем с Google Doc. MacType'ом сыт не будешь. Спасибо. Но для работы пока интерфейс небогатый и не очень продуманный: например, Ctrl+K не работает с выделенным текстом. Очень жду обновлений интерфейса.
Ну и с лицензиями не совсем понятно сразу, могу ли я бесплатную версию использовать в коммерческих целях.
Несколько дней назад приходил отправленный с Яндекс.Почты текст, но не приходили вложения. Позже другое вложение "пришло": ссылка есть — файла нет.
Ещё не успели. Последнюю по IndexedDB завели 26 апреля 2021 года
Из блога Vivaldi:
Короче говоря, Хромиум только рендерит страницы. Не всё так плохо.
Спасибо! Поправили всё.
Насколько я понимаю, под минимизацией корпуса автор имеет в виду технику, когда программа тестирования сокращает количество входных данных, ориентируясь на сам код. Минимизация по определению направлена на сокращение чего-либо, поэтому программу не интересуют надмножества, расширенные наборы и т.п., она сделана так, чтобы обращать внимание на подмножества, затачивая подаваемые данные под них.
То есть руками вы, конечно, придумаете нужную комбинацию, а вот автоматы эту штуку упустят из-за оптимизаций. Как у Кнута: «Преждевременная оптимизация — корень всех зол». Думаю, «никогда» — это преувеличение, чтобы обратить внимание на проблему. Иначе бы автор сам ничего не нашёл.
В go автоформат даже из коробки; но там сам язык располагает, а у Python, скорее всего, дело в смысле отступов — подход нужен аккуратный, поэтому автоформат пишется долго и трудно. Ждём. И может быть поможет: список отобранных форматтеров.
Согласен. Но в разработке ситуация, видимо, стала лучше:
Этот текст уже в основном о России.
Спасибо, что вспомнили. Этот обзор в основном мировой, темы 1С мы, по возможности, коснёмся в других статьях.
Спасибо, уточнили: 344% — это прогнозируемый рост (на основе известных данных), а не точный в сравнении с цифрами прошлого.
Пока что эта программа заменяется зрелыми клиентами, например QuiteRSS, но чувствуется, что QRSS может умереть в плане поддержки. RSSOwl — на Java. Но там не хватает адекватной чистки новостей.
Прочие клиенты страшно тяжёлые и не заточены под условного технаря, которому нужно полноценное информационное поле, а здесь есть этот потенциал после множества переосмыслений. Третьи вообще совсем мелкие поделки, четвёртые — веб, что далеко не всегда удобно. И т. д.
Короче говоря — не останавливайтесь. Буду рад лет через несколько увидеть клиент с хорошо заточенными фильтрами и аккуратной работой именно с поиском. Такие штуки востребованы среди тех, кто плотно работает с новостями.
Есть и другие подобные запросы, список можно посмотреть здесь. И вот здесь рассказывается о поддержке таких запросов браузерами.
Вы правы, но имеете в виду другое лидерство: в 2007, 2010, 2018 и 2020 Python был языком года, то есть его популярность росла быстрее популярности других языков, но Python ещё не был самым популярным.