Лучше использовать всё стандартное, что бы зайдя на рандомный сервер, можно было всё делать на автомате, а не вспоминать в чём же там отличия.
Да не такая это и проблема. Я на своём компьютере использую ripgrep и fd, но на чужих у меня нет никаких проблем с тем, чтобы на автомате запустить grep и find.
Хорошо. Приведите, пожалуйста, ссылки, подкрепляющую утверждение, что рекомендация «растёт из необходимости смотреть на клавиатуру». Я в этом сомневаюсь, так как тогда в большинстве рекомендаций был бы больший угол и монитор располагался бы ниже (как в австралийских рекомендациях).
Вообще, оказалось очень сложно выделить какие-то конкретные утверждения из ваших комментариев. Вы сразу перешли на обсуждение личности составителей рекомендаций и выражение скепсиса. Поэтому я был бы признателен, если бы вы чётко сформулировали свою позицию.
Что именно переврали «копирайтеры» в рекомендациях? Какие рекомендации верные?
И вместо того, чтобы приводить ссылки на рекомендации, составленные непонятно кем, попробуйте исследовать вопрос с другой стороны.
Тогда сошлюсь на E. H. C. Woo, P. White & C. W. K. Lai (2016) Ergonomics standards and guidelines for computer workstation design and the impact on users’ health – a review, Ergonomics, 59:3, 464-475, DOI: 10.1080/00140139.2015.1076528:
Вот цитата оттуда:
Proper positioning of the computer monitor is essential to prevent neck and eye strain. Most guidelines recommend that the monitor should be placed at or below eye level in order to maintain a comfortable viewing angle and distance to the screen (Labour Department 2010). It should also be directly in front of the user if the screen is viewed continuously or frequently (CSA 1989, 2000). Current ergonomics standards specify a certain range of viewing angles and distances. However, there is conflict over which settings and locations may have different standards for viewing angle. For example, AS-3590.2 proposes a low monitor position that is between 32° and 45° below horizontal eye level (Standards Australia 1990); while ANSI/HFES-100 proposes a mid-position that is between 15° and 25° (ANSI 1988). The inconsistency may be due to differences in monitor heights and positions with respect to the effect on the neck and visual system (Straker 2000). The argument for lower monitor position is due to subjective preference for the target to be located such that the eyes gaze downward relative to the head (Heuer et al. 1991), a reduction in ocular surface area (Sotoyama et al. 1996) and a decrease in visual fatigue (Jaschinski, Heuer, and Kylian 1998). However, if the monitor is either too low or too high, it can lead to an increase in either flexion or extension of the head (atlanto-occipital angle) relative to the neck (Burgess-Limerick, Plooy, and Ankrum 1998; Burgess-Limerick, Plooy, and Mon-Williams 1998; Burgess-Limerick et al. 1999; Burgess-Limerick, mon-Williams, and Coppard 2000), and an increase in cervical muscle activity (Psihogios et al. 2001; Straker and mekhora 2000; Turville et al. 1998). Despite there being a trade-off between visual and musculoskeletal strains with regard to optimal height of monitor position, Sommerich, Joines, and Psihogios (2001) proposed a conceptual U-shaped model to depict the conflict, and suggested the viewing angle at a range of 0° to approximately 45° below eye level. Most publications recommend a mid-position ranging from 15° to 25° below gaze inclination (Chen and Zhong 1999; Hagberg and rempel 1997; Sheedy and Shaw-McMinn 2003).
В статье много ссылок на исследования и таблица со сравнением рекомендаций из разных официальных источников.
Казалось бы, давно разобрались, как "текстописатели"-"рерайтеры" переврали первоисточник. Но идею продолжают тиражировать.
Приведите, пожалуйста, ссылку на первоисточник. Или просто ссылку на рекомендации располагать монитор выше уровня глаз. Я пока ни одной не нашёл.
Зачем? Зачем их запоминать специально? Все нужные слова будут запомнены в процессе чтения/письма/говорения безо всяких ненужных эмоций. Неиспользуемые слова неизбежно будут забыты.
Потому что это эффективнее. Чтобы не отвлекаться во время чтения на словарь, и чтобы во время разговора не прерывать собеседника (что не всегда возможно). Например, перед первым походом в магазин в новой стране неплохо бы полистать разговорник заранее.
Это не значит, что нужно учить весь словарь слово за словом, но и недооценивать такой подход тоже не стоит.
Пароль должен быть именно что бессмысленными, из букв, цифр и спецсимволов
У парольных фраз из нескольких слов очень хорошая энтропия и их намного легче запомнить.
«Ленусик, 1987 года рождения» (с кириллицей, запятой и цифрами) — это как раз очень даже неплохой пароль. :)
С другой стороны после 5-6 раз, я 12-символьные случайные пароли тоже запоминаю.
Да, действительно. Я ошибся. Можно указать, откуда брать версию, в tool.setuptools.dynamic.
Любопытно, что я видел это в документации, но забыл. Видимо, проекты, в которых в setup.py регуляркой достают версию из файла, создали стойкую ассоциацию, что setuptools самостоятельно это сделать не может. :)
pyenv — менеджер интерпретаторов и виртуальных окружений.
Hatch — относительно новая система сборки под крылом PyPA, но поддерживает все соответствующие PEP. Перешёл на неё с Poetry и не жалею.
Кстати, я заметил, что многие отказываются от систем сборки якобы из-за того, что придётся пользоваться новыми утилитами, а изучать их не хочется. Это не так. Можно перенести все зависимости в pyproject.toml (setup.py для простого перечисления зависимостей не нужен и не рекомендуется), указать систему сборки, отличную от setuptools и не пользоваться ничем кроме pip. Даже колёса можно собирать с помощью pip wheel (хотя лучше python3 -m build).
Из полезных особенностей, которых нет в setuptools — динамические версии из коробки (может сам читать версию из указанного файла), умеет создавать окружение для разработки, умеет запускать команды для матрицы версий (tox становится не нужен).
Hatch пока сам не умеет фиксировать зависимости (автор ждёт, когда такой функционал появится в pip), но можно пользоваться pip-tools. pip-compile отлично понимает зависимости в pyproject.toml.
pyright — тайпчекер. Мне он нравится больше mypy тем, что он быстры и просто работает из коробки без какой-либо настройки и телодвижений. Сам он написан не на Python (, но есть пакет, который можно поставить через pip. Он сам подтянет всё, что нужно. Из-за его скорости, его вполне можно добавить в pre-commit.
py-spy — профайлер. Киллер-фича — способность подключиться к уже запущенному процессу и показывать, какие именно функции сейчас работают. Как top/htop в линукс.
Запоминание — это больше, чем подготовка к ЕГЭ. Если что-то понять, но не запомнить, то толку от понимания не будет. Умения и навыки, которые дёт решение задач тоже непосредственно связаны с памятью.
Решая ученик запоминает шаблон задачи, приёмы решения. Это тоже запоминание, только уже высокоуровневой информации. Другое дело, что тут уже сложнее карточки делать, но можно применить метод интервальных повторений к задачам.
Мне кажется, вы неправильно поняли основную идею. Зазубривание таблицы синусов — это то самое механическое запоминание низкоуровневой информации, о котором говорится в статье.
С точки зрения пользователя это всё не очень-то важно.
Статическая типизация и single binary — это удобно, но это лишь немного упрощает установку, а не использование.
JIT скриптам для сборки не очень-то нужен. Большую часть времени занимает сама сборка.
Впрочем, довольно странно сравнивать MSBuild от чистый Python. Первое — это система сборки, а второе — язык программирования. Если выбор между написанием скрипта руками и MSBuild, то для проекта больше пары файлов я б предпочёл MSBuild, который что-то уже умеет делать сам.
Но MSBuild — это очень низкоуровневая штука. Вряд ли кто-то пишет здоровенные XML с описанием проекта руками. Гораздо удобнее сделать инструмент, который будет по более высокоуровневому описанию генерировать проект для MSBuild.
По этой же причине странно сравнивать make и cmake. Первый низкоуровневый, а второй высокоуровневый. CMake просто генерирует код для make, Ninja (мой любимый вариант) или того же MSBuild.
И вот оказалось, что Python очень удобен как DSL для таких высокоуровневых инструментов. XML слишком декларативен. Для сложного проекта его может не хватать, а если добавить динамики это будет выглядет громоздко.
Потому и появились SCons (хотя я его редко вижу) и Conan (очень популярен, но это не совсем система сборки). В Bazel сделали чуть интереснее. Там в качестве DSL используется не Python, а его безопасное подмножество — Starlark.
У такого подхода есть недостатки. В общем случае декларативность удобнее, чем императивность. Но тут много зависит от проекта, так что подход вполне имеет право на существование.
Это вопрос к разработчикам этого конкретного проекта, которые решили использовать Python для скриптов или какой-то инструмент на python (например, Conan). И использовали неправильно, раз есть подтормаживания.
Странный вопрос. Это как если бы я написал, что ничего не имею против C, но посетовал, что прошивка на одном из моих устройств глючная.
Спасибо за уточнение! Да, пример неудачный. Я просто хотел сказать, что бывают случаи, когда перед аббревиатурами ставится артикль. Если это не страна, то тоже есть примеры. Например, the DVD или the UN. Впрочем, скажем, NASA и UNESCO пишутся без артикля.
В любом случае изначальный тезис был не об этом, а о том, что порой в языке логики нет и надо просто запомнить. :)
Тексты сильно зависят от того, на сколько "однообразны/разнообразны" твои тексты и задачи ранее введенные в диалоге.
Кстати, по моему опыту контекст на разнообразие не особо влияет. На него намного сильнее влияют параметры сэмплинга. Говорят, что раньше можно было указывать температуру в веб-интерфейсе, но я довольно поздно подключился и эту настройку уже не видел.
Да и я упомянул однообразие просто как интересный факт. Вы слишком много внимание ему уделили в своём своём комментарии. Это не самая большая проблема.
Условный Стивен Кинг может спокойно работать на чате/вместе с чатом, принимая его недостатки и интерпретируя их.
Зачем Стивену Кингу тратить кучу творческих усилий и выдавливать что-то из модели? Не проще ли уже самому придумать?
А технарь слишком зашоренно будит смотреть на отрасль на чужую отрасль, вместо подхода
Не уверен, что я понял, как это относится к моему комментарию.
Например, для меня языковые модели — это часть основной работы, это как раз моя отрасль.
Я лишь хотел сказать, что в нынешнем виде chatGPT стоит использовать с осторожностью, так как она с уверенностью может говорить что-то правдоподобное, но неверное. Я не отрицаю, что прогресс огромный, и в будущем эти недостатки наверняка будут устранены. Но сейчас лично для себя практического применения я не вижу. Как консультант она ненадёжна, как генератор чего-то нового требует неоправданно много усилий.
Да не такая это и проблема. Я на своём компьютере использую ripgrep и fd, но на чужих у меня нет никаких проблем с тем, чтобы на автомате запустить grep и find.
Да нет, вроде всё верно. Если я верно понял автора, то утверждается следующее.
«Статическая защита» — использование статических анализаторов, статической типизации и т. д.
«Статистическая защита» — это когда берут количеством, а не качеством.
Хорошо. Приведите, пожалуйста, ссылки, подкрепляющую утверждение, что рекомендация «растёт из необходимости смотреть на клавиатуру». Я в этом сомневаюсь, так как тогда в большинстве рекомендаций был бы больший угол и монитор располагался бы ниже (как в австралийских рекомендациях).
Вообще, оказалось очень сложно выделить какие-то конкретные утверждения из ваших комментариев. Вы сразу перешли на обсуждение личности составителей рекомендаций и выражение скепсиса. Поэтому я был бы признателен, если бы вы чётко сформулировали свою позицию.
Что именно переврали «копирайтеры» в рекомендациях? Какие рекомендации верные?
Тогда сошлюсь на E. H. C. Woo, P. White & C. W. K. Lai (2016) Ergonomics standards and guidelines for computer workstation design and the impact on users’ health – a review, Ergonomics, 59:3, 464-475, DOI: 10.1080/00140139.2015.1076528:
Вот цитата оттуда:
В статье много ссылок на исследования и таблица со сравнением рекомендаций из разных официальных источников.
Приведите, пожалуйста, ссылку на первоисточник. Или просто ссылку на рекомендации располагать монитор выше уровня глаз. Я пока ни одной не нашёл.
Потому что это эффективнее. Чтобы не отвлекаться во время чтения на словарь, и чтобы во время разговора не прерывать собеседника (что не всегда возможно). Например, перед первым походом в магазин в новой стране неплохо бы полистать разговорник заранее.
Это не значит, что нужно учить весь словарь слово за словом, но и недооценивать такой подход тоже не стоит.
У парольных фраз из нескольких слов очень хорошая энтропия и их намного легче запомнить.
«Ленусик, 1987 года рождения» (с кириллицей, запятой и цифрами) — это как раз очень даже неплохой пароль. :)
С другой стороны после 5-6 раз, я 12-символьные случайные пароли тоже запоминаю.
Я не уверен, что готов читать «Поминки по Финнегану» даже в переводе. :)
Нет, просто если центр монитора на уровне глаз или выше, то шея устаёт.
Во всех руководствах по эргономике, что я видел, рекомендуется располагать центр монитора ниже линии зрения. (Например, это или это.)
Если вы поделитесь ссылкой на руководство или статью, где рекомендуется обратное, было бы здорово.
Согласно рекомендациям по эргономике центр монитора должен быть на 15-20 градусов ниже уровня глаз. Не слишком низко, но и не слишком высоко.
И в C++ (Cling). :)
Haskell и лиспы слишком разные, чтоб их сравнивать. А то так APL победит в лаконичности.
А что такое сокращённая форма адреса? Живу в Англии, не сталкивался с таким.
Да, действительно. Я ошибся. Можно указать, откуда брать версию, в
tool.setuptools.dynamic.Любопытно, что я видел это в документации, но забыл. Видимо, проекты, в которых в setup.py регуляркой достают версию из файла, создали стойкую ассоциацию, что setuptools самостоятельно это сделать не может. :)
Навскидку добавлю.
pyenv — менеджер интерпретаторов и виртуальных окружений.
Hatch — относительно новая система сборки под крылом PyPA, но поддерживает все соответствующие PEP. Перешёл на неё с Poetry и не жалею.
Кстати, я заметил, что многие отказываются от систем сборки якобы из-за того, что придётся пользоваться новыми утилитами, а изучать их не хочется. Это не так. Можно перенести все зависимости в pyproject.toml (setup.py для простого перечисления зависимостей не нужен и не рекомендуется), указать систему сборки, отличную от setuptools и не пользоваться ничем кроме pip. Даже колёса можно собирать с помощью pip wheel (хотя лучше python3 -m build).
Из полезных особенностей, которых нет в setuptools — динамические версии из коробки (может сам читать версию из указанного файла), умеет создавать окружение для разработки, умеет запускать команды для матрицы версий (tox становится не нужен).
Hatch пока сам не умеет фиксировать зависимости (автор ждёт, когда такой функционал появится в pip), но можно пользоваться pip-tools. pip-compile отлично понимает зависимости в pyproject.toml.
pyright — тайпчекер. Мне он нравится больше mypy тем, что он быстры и просто работает из коробки без какой-либо настройки и телодвижений. Сам он написан не на Python (, но есть пакет, который можно поставить через pip. Он сам подтянет всё, что нужно. Из-за его скорости, его вполне можно добавить в pre-commit.
py-spy — профайлер. Киллер-фича — способность подключиться к уже запущенному процессу и показывать, какие именно функции сейчас работают. Как top/htop в линукс.
memray — профилировщик памяти.
Если ещё что-то вспомню, то напишу. :)
Пара дополнений про упомянутые в статье пакеты.
К сожалению, ruff пока трудно назвать заменой flake8, так как сила последнего в плагинах, но штука классная.
У rich классная визуализация исключений.
Запоминание — это больше, чем подготовка к ЕГЭ. Если что-то понять, но не запомнить, то толку от понимания не будет. Умения и навыки, которые дёт решение задач тоже непосредственно связаны с памятью.
Решая ученик запоминает шаблон задачи, приёмы решения. Это тоже запоминание, только уже высокоуровневой информации. Другое дело, что тут уже сложнее карточки делать, но можно применить метод интервальных повторений к задачам.
Хорошая память действительно помогает учиться.
Мне кажется, вы неправильно поняли основную идею. Зазубривание таблицы синусов — это то самое механическое запоминание низкоуровневой информации, о котором говорится в статье.
С точки зрения пользователя это всё не очень-то важно.
Статическая типизация и single binary — это удобно, но это лишь немного упрощает установку, а не использование.
JIT скриптам для сборки не очень-то нужен. Большую часть времени занимает сама сборка.
Впрочем, довольно странно сравнивать MSBuild от чистый Python. Первое — это система сборки, а второе — язык программирования. Если выбор между написанием скрипта руками и MSBuild, то для проекта больше пары файлов я б предпочёл MSBuild, который что-то уже умеет делать сам.
Но MSBuild — это очень низкоуровневая штука. Вряд ли кто-то пишет здоровенные XML с описанием проекта руками. Гораздо удобнее сделать инструмент, который будет по более высокоуровневому описанию генерировать проект для MSBuild.
По этой же причине странно сравнивать make и cmake. Первый низкоуровневый, а второй высокоуровневый. CMake просто генерирует код для make, Ninja (мой любимый вариант) или того же MSBuild.
И вот оказалось, что Python очень удобен как DSL для таких высокоуровневых инструментов. XML слишком декларативен. Для сложного проекта его может не хватать, а если добавить динамики это будет выглядет громоздко.
Потому и появились SCons (хотя я его редко вижу) и Conan (очень популярен, но это не совсем система сборки). В Bazel сделали чуть интереснее. Там в качестве DSL используется не Python, а его безопасное подмножество — Starlark.
У такого подхода есть недостатки. В общем случае декларативность удобнее, чем императивность. Но тут много зависит от проекта, так что подход вполне имеет право на существование.
Это вопрос к разработчикам этого конкретного проекта, которые решили использовать Python для скриптов или какой-то инструмент на python (например, Conan). И использовали неправильно, раз есть подтормаживания.
Странный вопрос. Это как если бы я написал, что ничего не имею против C, но посетовал, что прошивка на одном из моих устройств глючная.
Спасибо за уточнение! Да, пример неудачный. Я просто хотел сказать, что бывают случаи, когда перед аббревиатурами ставится артикль. Если это не страна, то тоже есть примеры. Например, the DVD или the UN. Впрочем, скажем, NASA и UNESCO пишутся без артикля.
В любом случае изначальный тезис был не об этом, а о том, что порой в языке логики нет и надо просто запомнить. :)
А, точно! Я пропустил фразу про калибровку.
Кстати, по моему опыту контекст на разнообразие не особо влияет. На него намного сильнее влияют параметры сэмплинга. Говорят, что раньше можно было указывать температуру в веб-интерфейсе, но я довольно поздно подключился и эту настройку уже не видел.
Да и я упомянул однообразие просто как интересный факт. Вы слишком много внимание ему уделили в своём своём комментарии. Это не самая большая проблема.
Зачем Стивену Кингу тратить кучу творческих усилий и выдавливать что-то из модели? Не проще ли уже самому придумать?
Не уверен, что я понял, как это относится к моему комментарию.
Например, для меня языковые модели — это часть основной работы, это как раз моя отрасль.
Я лишь хотел сказать, что в нынешнем виде chatGPT стоит использовать с осторожностью, так как она с уверенностью может говорить что-то правдоподобное, но неверное. Я не отрицаю, что прогресс огромный, и в будущем эти недостатки наверняка будут устранены. Но сейчас лично для себя практического применения я не вижу. Как консультант она ненадёжна, как генератор чего-то нового требует неоправданно много усилий.