@DRoman0v, в обзорах на эти наушники часто утверждается, что шумодав работает на столько эффективно, что внешние звуки просто исчезают. В вашей статье заявление не столь категоричное, но и про шумодав написано не очень много. Как он вам вообще?
Долго не отвечал - был в шоке. Получается, что я был не прав, однако не могу одобрить такого решения. От себя я бы всё-таки рекомендовал использовать OrderedDict там, где важен порядок ключей, этим вы как бы говорите коллегам - "тут нам очень важен порядок ключей, и это не просто так". Речь, конечно же, про код, который нужно сопровождать, в одноразовых скриптах это не важно.
Благодаря динамической природе Python, в нём не видна суть кортежа - благодаря этому он воспринимается как "просто неизменяемый список". Однако суть его совсем в другом, и это видно только в статических языках, например в Rust. Я воспринимаю эту разницу так: список - это изменяемая последовательность однородных данных, кортеж - это неизменяемый набор разнородных данных. Он потому неизменяемый, так как данные разнородны и в статических языках мы не можем заменить тип элемента кортежа. В Python эта разница размывается, так как в списке могут быть ссылки на объекты разных типов. В этой статье этот момент упоминался:
Используйте кортеж, когда данные — это структура
На мой взгляд, это основное предназначение кортежа, как типа данных. Но в Python его, конечно же, можно использовать и в качестве неизменяемого списка.
Теперь можно безопасно полагаться на порядок словаря
Нет, нельзя не стоит. Для сохранения порядка ключей в словаре используйте OrderedDict, потому что природа словарей, как и любого другого Map - не полагаться на порядок вставки элементов. Текущее поведение - побочный эффект оптимизации использования памяти словарями, в будущих версиях Python все может измениться. Если не ошибаюсь, то даже в доках это где-то указывалась.
ORM - хороший инструмент для простых CRUD операций.
Недавно встречал мнение, что Django ORM годится как раз для простых случаев, тогда как для более сложных лучше подходит SQLAlchemy. Вот с Алхимией я как раз тесно работаю, не скажу, что знаю эту библиотеку досконально, но со сложными запросами она справляется просто замечательно - кучи join, агрегации и прочие замечательные штуки нашей непростой бизнес-логики. Очень сильно облегчают жизнь явное указание связей между таблицами, а так же всякие оптимизации типа joinedload. Запросы отлаживаются, изменяются без проблем, то есть поддерживать их довольно просто, на мой взгляд.
Так что мне кажется, что в PHP описываемые проблемы касаются данных конкретных ORM, а не ORM в целом. Но, к сожалению, иногда инструмент прибит гвоздями к фреймворку, поэтому выбора нет.
Всё-таки, выбирая лучший язык для обучения, нужно учитывать цели этого самого обучения. Если учат будущих программистов, то Pascal однозначно лучше, чем Python, но вообще-то стоит подумать про C вместо Паскаля. Если язык программирования учат как дополнительный курс, не с целью стать программистом, просто, как удобный инструмент, то возможно Python будет лучше, потому что он может пригодится практически во многих сферах.
Мне всё-таки кажется, что удел Pascal - это школы, потому что школьники ещё не знают, в какую сторону они пойдут, а этот язык заложит академические основы программирования, при этом сам по себе он в будущем не пригодится.
Как вам уже ответили, масса имеет очень большое значение при вибронагрузках. Которые очень сильно отличаются на самокате/моноколесе и легковом автомобиле. Поэтому в легковых машинах основная масса располагается на подвеске, а сами колёса - чем легче, тем лучше.
И, предугадывая следующий ответ - при одинаковой амплитуде и частоте вибрации, но разной массе - вибронагрузка будет разная.
Ну, а по массу, вы конечно забыли? Речь идёт о мотор-колесах легковых автомобилей весом "пару тонн", которые упоминались в комментарии, на который я отвечал изначально.
Не сравнивайте легковой автомобиль с самокатом/моноколесом. Слишком разная масса, как самого средства, колеса, так и двигателя. И скорость очень разная
Могу ошибаться, но мотор-колесо на гражданском транспорте - скорее исключение, чем правило. В основном электродвигатель как раз на подвеске и стоит, чтобы не делать сами колеса слишком тяжёлыми. Плюс требования к вибро-устойчивости такого двигателя на колесе сделают его слишком дорогим. Повторюсь, что могу ошибаться, так что поправьте, если мои рассуждения не верны.
этап когда читать 2-3 страницы текста стало не напряжно
Очень много зависит от конкретной книги. Я примерно так прочитал всего Гарри Поттера (на русском не читал до этого). А потом я как-то взялся за Dune Фрэнка Херберта, которую люблю с детства - я не вылезал из словаря, и в конце концов бросил это дело. Кстати, Harry Potter and Methods of Rationality читается даже лучше Роулинг. JFYI
Большие числа. «1+1=2» я могу посчитать на английском, но когда начинаешь оперировать с большими числами, то переключаешься на русский язык, затем делаешь математическую операцию, затем результат переводится на английский.
Кроме чисел у меня аналогичная проблема с днями недели и временем. С числами ещё возникает неловкая ситуация, когда для ответа нужно что-то посчитать не слишком сложное, но ты зависаешь на этапе трансляции входных данных, потом результата. А выглядит все это как будто ты считать не умеешь.
Однако вендоры low-code платформ предлагают основной рабочей лошадкой назначить аналитиков, а не разработчиков, оставив последним совсем уж специфичные задачи.
Я понимаю это так: аналитики "возят мышкой по экрану", формируя бизнес логику из кубиков (простите за формулировку), а программисты создают этим самые кубики. Звучит, в принципе, не плохо. Однако на практике может прозвучать "выжпрограмисты - вот и делайте всё. Это же упрощает вашу работу". Работал я как-то с подобной системой автоматизации бизнес-процессов. С тех пор я ненавижу low-code, простите.
Тут опять же проверка на базовое знание языка. Выражения if 55: на самом деле выполняется так: if bool(55): Ну, а оператор сравнения работает со значениями, поэтому 55 == True вернёт False.
Но если честно, то очень часто такие "элементарные" задачки формулируются таким образом, что они вместо теста на знание языка превращаются в тест на внимательность. Поэтому с ними лучше не переборщить.
Да видел я про Технику Молодежи, и ссылку на Википедии посещал, когда уточнял, правильно ли я помню про ЗГГОГи ))) Спасибо за ТМ, с же вам кивал плюсик поставил, но та книга мне очень сильно олдскулы свела, особенно тем, что я наконец-то окончательно убедился, что цифра 2 на ней не просто так. Можно сказать, что одна из величайших тайн моей жизни открыта ))
Как-то очень давно пробовал подобный чай. У него был особый (слабительный) эффект после употребления. Может именно в этом смысл подобных чаёв?
@DRoman0v, в обзорах на эти наушники часто утверждается, что шумодав работает на столько эффективно, что внешние звуки просто исчезают. В вашей статье заявление не столь категоричное, но и про шумодав написано не очень много. Как он вам вообще?
Вы, случайно, не к iPhone подключаете? Как я понимаю, Apple не поддерживает LDAC
Долго не отвечал - был в шоке. Получается, что я был не прав, однако не могу одобрить такого решения.
От себя я бы всё-таки рекомендовал использовать OrderedDict там, где важен порядок ключей, этим вы как бы говорите коллегам - "тут нам очень важен порядок ключей, и это не просто так". Речь, конечно же, про код, который нужно сопровождать, в одноразовых скриптах это не важно.
Благодаря динамической природе Python, в нём не видна суть кортежа - благодаря этому он воспринимается как "просто неизменяемый список". Однако суть его совсем в другом, и это видно только в статических языках, например в Rust.
Я воспринимаю эту разницу так: список - это изменяемая последовательность однородных данных, кортеж - это неизменяемый набор разнородных данных. Он потому неизменяемый, так как данные разнородны и в статических языках мы не можем заменить тип элемента кортежа. В Python эта разница размывается, так как в списке могут быть ссылки на объекты разных типов.
В этой статье этот момент упоминался:
На мой взгляд, это основное предназначение кортежа, как типа данных. Но в Python его, конечно же, можно использовать и в качестве неизменяемого списка.
ИМХО. Критика приветствуется.
Нет,
нельзяне стоит. Для сохранения порядка ключей в словаре используйте OrderedDict, потому что природа словарей, как и любого другого Map - не полагаться на порядок вставки элементов. Текущее поведение - побочный эффект оптимизации использования памяти словарями, в будущих версиях Python все может измениться. Если не ошибаюсь, то даже в доках это где-то указывалась.Недавно встречал мнение, что Django ORM годится как раз для простых случаев, тогда как для более сложных лучше подходит SQLAlchemy. Вот с Алхимией я как раз тесно работаю, не скажу, что знаю эту библиотеку досконально, но со сложными запросами она справляется просто замечательно - кучи join, агрегации и прочие замечательные штуки нашей непростой бизнес-логики. Очень сильно облегчают жизнь явное указание связей между таблицами, а так же всякие оптимизации типа joinedload. Запросы отлаживаются, изменяются без проблем, то есть поддерживать их довольно просто, на мой взгляд.
Так что мне кажется, что в PHP описываемые проблемы касаются данных конкретных ORM, а не ORM в целом. Но, к сожалению, иногда инструмент прибит гвоздями к фреймворку, поэтому выбора нет.
Эта ветка комментариев не про новые движки, а про то, что на данный момент мотор-колёса - редкость в легковых автомобилях, и про то, почему это так.
Всё-таки, выбирая лучший язык для обучения, нужно учитывать цели этого самого обучения. Если учат будущих программистов, то Pascal однозначно лучше, чем Python, но вообще-то стоит подумать про C вместо Паскаля. Если язык программирования учат как дополнительный курс, не с целью стать программистом, просто, как удобный инструмент, то возможно Python будет лучше, потому что он может пригодится практически во многих сферах.
Мне всё-таки кажется, что удел Pascal - это школы, потому что школьники ещё не знают, в какую сторону они пойдут, а этот язык заложит академические основы программирования, при этом сам по себе он в будущем не пригодится.
Как вам уже ответили, масса имеет очень большое значение при вибронагрузках. Которые очень сильно отличаются на самокате/моноколесе и легковом автомобиле. Поэтому в легковых машинах основная масса располагается на подвеске, а сами колёса - чем легче, тем лучше.
И, предугадывая следующий ответ - при одинаковой амплитуде и частоте вибрации, но разной массе - вибронагрузка будет разная.
Ну, а по массу, вы конечно забыли? Речь идёт о мотор-колесах легковых автомобилей весом "пару тонн", которые упоминались в комментарии, на который я отвечал изначально.
Не сравнивайте легковой автомобиль с самокатом/моноколесом. Слишком разная масса, как самого средства, колеса, так и двигателя. И скорость очень разная
Могу ошибаться, но мотор-колесо на гражданском транспорте - скорее исключение, чем правило. В основном электродвигатель как раз на подвеске и стоит, чтобы не делать сами колеса слишком тяжёлыми. Плюс требования к вибро-устойчивости такого двигателя на колесе сделают его слишком дорогим.
Повторюсь, что могу ошибаться, так что поправьте, если мои рассуждения не верны.
Очень много зависит от конкретной книги. Я примерно так прочитал всего Гарри Поттера (на русском не читал до этого). А потом я как-то взялся за Dune Фрэнка Херберта, которую люблю с детства - я не вылезал из словаря, и в конце концов бросил это дело.
Кстати, Harry Potter and Methods of Rationality читается даже лучше Роулинг. JFYI
Кроме чисел у меня аналогичная проблема с днями недели и временем.
С числами ещё возникает неловкая ситуация, когда для ответа нужно что-то посчитать не слишком сложное, но ты зависаешь на этапе трансляции входных данных, потом результата. А выглядит все это как будто ты считать не умеешь.
Посмотрите на досуге исходники модуля
this, того самого Дзэна Питона ;-)Я понимаю это так: аналитики "возят мышкой по экрану", формируя бизнес логику из кубиков (простите за формулировку), а программисты создают этим самые кубики. Звучит, в принципе, не плохо. Однако на практике может прозвучать "выжпрограмисты - вот и делайте всё. Это же упрощает вашу работу". Работал я как-то с подобной системой автоматизации бизнес-процессов. С тех пор я ненавижу low-code, простите.
Подушню:
На самом деле их четыре. Есть даже специальная аббревиатура: правило LEGB - local, enclosed, global, built-in
Тут опять же проверка на базовое знание языка. Выражения
if 55:на самом деле выполняется так:if bool(55):Ну, а оператор сравнения работает со значениями, поэтому
55 == Trueвернёт False.Но если честно, то очень часто такие "элементарные" задачки формулируются таким образом, что они вместо теста на знание языка превращаются в тест на внимательность. Поэтому с ними лучше не переборщить.
Да видел я про Технику Молодежи, и ссылку на Википедии посещал, когда уточнял, правильно ли я помню про ЗГГОГи )))
Спасибо за ТМ, с же вам
кивалплюсик поставил, но та книга мне очень сильно олдскулы свела, особенно тем, что я наконец-то окончательно убедился, что цифра 2 на ней не просто так. Можно сказать, что одна из величайших тайн моей жизни открыта ))