про закладки это был больше крик души и старая ноющая мозоль... тем не менее, если вам не кажется такое поведение фичи "меню закладок" как минимум странным, то я не смогу вас переубедить по данному моменту.
Замечу, что ваш комментарий все-таки подтверждает мой тезис о том, что разные люди пользуются разными фичами, и нет смысла добавлять их все в основное приложение. Особенно когда есть чудесный маркет, где все плагины ставятся в один клик.
Раз уж в статье спросили, что я думаю, то не могу не сказать: эта опция абсолютный не-musthave, как и множество других функций. И по-хорошему они должны быть вынесены отдельными плагинами. А сам браузер в свежеустановленном виде должен быть максимально базовой комплектации. И тогда всем будет счастье. Я firefox все еще не могу простить исчезающую панель закладок в полноэкранном режиме и не знаю, какими танцами с бубном это исправить, а если такие фичи будут плодиться - то мне страшно становится....
Да, все правильно говорите: все бегуны окажутся (или нет) одинокими рано или поздно. Но не обязательно одновременно. Каждый из людей, живущих на Земле, был рожден. Все люди были рождены. Но не значит, что они были рождены одновременно.
В конце статьи есть раздел "Зачем нужна вся эта беготня", наверно, автор позже дописал, либо не заметили. Но математика, пожалуй, одна из немногих наук, где логическая цепочка между "дано" и "доказать, что..." интересна сама по себе, а не в прикладном контексте
Сколько знаю про эту опцию, руки чешутся её попробовать применить куда-нибудь, да за несколько лет работы со стеком Python+Postgres не подвернулось случая, где это действительно было бы полезно (для меня).
Не говорю, что фича плохая (даже наоборот, кажется очень перспективной), но на практике не сталкивался, ожидал тут прочитать об этом. Не хватает реально показательного примера (-ов), где можно было бы предпочесть такой способ внешней логике с вызовом SQL. Может мне в комментарии накидают примеров :)
Всегда найдутся люди, которые уверуют во что-то нетривиальное, для кого-то же пишут на упаковках бургера, что они не съедобны... Вы кстати тоже сделали вывод об ошибочности мысли автора всего лишь по одной фразе)
Так и не понял, почему State Machine не может быть вложенной ( и как следствие иметь глобальные переходы между состояниями) и почему невозможно параллельное выполнение состояний (даже не совсем понял, что это такое. Если к игровому объекту привязано 2 разных State Machine , можно ли считать это параллельным?) ?
Видимо, статья посвящена Unity, хотя не нашел в статье примеров использования ни того, ни другого, поэтому не могу точно сказать. Возможно, по списку хабов мне надо офильтровывать статьи, но хотелось бы в названии видеть, с чем имеем дело.
С абстрактной точки зрения, что SM, что дерево - оба графы, с разными свойствами. Не понимаю, почему один из них по древним заветам ситхов низведен до абсолюта НИКОГДА-не-использования.
Видимо просто ожидания не совпадают с реальностью. Подобный пост с Альфой или Сбером даже взгляда не зацепит, а от Тинькофф все еще по инерции ожидают "современного" и "инновационного" обслуживания без косяков и обманов.
в моей практике часто баловался с перечислениями в питоне: и наследовал, и записывал им в value объекты кастомных классов, динамически генерировал enum из справочника в БД и были попытки "магии" с __set_name__ ...
Безусловно, это дало нехилый буст в понимании работы многих аспектов работы питона, но сами наработки были в подавляющем числе нежнеспособны - пользоваться можно только копипастом уже используемых примеров, а последующие доработки новых механик несоизмеримо профиту усложняли код.
как итог - с enum теперь работаю исключительно как с набором литералов (максимум использую enum.IntEnum и enum.StrEnum) и сплю спокойно по ночам
Также (учитывая, что статья явно ссылается на Google Analytics) будет более корректным упомянуть, что Google отказывается от нескольких упомянутых в обзоре моделей атрибуции, в т.ч. от линейной и от атрибуции по первому клику (из-за чего нам под потребности клиента пришлось использовать опенсорсный счетчик).
Разнообразие выбора нам показали, но с ним и так сталкиваются все буквально первым же шагом, как касаются этой области. Будет классно дополнить статью продолжением с кейсами, сравнениями с разных точек зрения и соответствующими выводами. Ждем! Любые цифры и графики скажут больше, чем заранее известные прописные истины дижитал- (и не только) сфер "Одно (иногда) работает лучше другого" и "Чем больше факторов учтем, тем точнее будет прогноз".
[абсолютных утверждений вида "учитывая все факторы" также стоит избегать, иначе (откройте форточку) вам либо не поверят, либо попросят доказать утверждаемую всеобщность, из-за чего фокус внимания сместиться от того, что вы хотели донести.]
Хорошая статья на почитать вечерком! И было бы супер, если бы описание работы кода предшествовало самому коду. Ибо смотреть реализацию после объяснения - благое дело, а вот читать объяснение, после того как ты уже понял код - увы...
Аналогию понял, но тезис, в пользу которого Вы её используете, - нет. Мне правда интересно, что Вы имели ввиду, сможете поподробнее описать недостатки размышлений автора и чем плохо "всегда снимать" ?
про закладки это был больше крик души и старая ноющая мозоль... тем не менее, если вам не кажется такое поведение фичи "меню закладок" как минимум странным, то я не смогу вас переубедить по данному моменту.
Замечу, что ваш комментарий все-таки подтверждает мой тезис о том, что разные люди пользуются разными фичами, и нет смысла добавлять их все в основное приложение. Особенно когда есть чудесный маркет, где все плагины ставятся в один клик.
Раз уж в статье спросили, что я думаю, то не могу не сказать: эта опция абсолютный не-musthave, как и множество других функций. И по-хорошему они должны быть вынесены отдельными плагинами. А сам браузер в свежеустановленном виде должен быть максимально базовой комплектации. И тогда всем будет счастье.
Я firefox все еще не могу простить исчезающую панель закладок в полноэкранном режиме и не знаю, какими танцами с бубном это исправить, а если такие фичи будут плодиться - то мне страшно становится....
Да, все правильно говорите: все бегуны окажутся (или нет) одинокими рано или поздно. Но не обязательно одновременно.
Каждый из людей, живущих на Земле, был рожден. Все люди были рождены. Но не значит, что они были рождены одновременно.
В конце статьи есть раздел "Зачем нужна вся эта беготня", наверно, автор позже дописал, либо не заметили. Но математика, пожалуй, одна из немногих наук, где логическая цепочка между "дано" и "доказать, что..." интересна сама по себе, а не в прикладном контексте
замечу, что в цитате нет слова "одновременно"
Сколько знаю про эту опцию, руки чешутся её попробовать применить куда-нибудь, да за несколько лет работы со стеком Python+Postgres не подвернулось случая, где это действительно было бы полезно (для меня).
Не говорю, что фича плохая (даже наоборот, кажется очень перспективной), но на практике не сталкивался, ожидал тут прочитать об этом. Не хватает реально показательного примера (-ов), где можно было бы предпочесть такой способ внешней логике с вызовом SQL. Может мне в комментарии накидают примеров :)
Всегда найдутся люди, которые уверуют во что-то нетривиальное, для кого-то же пишут на упаковках бургера, что они не съедобны... Вы кстати тоже сделали вывод об ошибочности мысли автора всего лишь по одной фразе)
топ 1 язык для программирования на бумаге
Нет, пуэр не закапывают и не должны закапывать в землю
Не нашел в гугле инфу, поэтому обращаюсь к вам напрямую, может плохо искал. Как именно сигнал уничтожал форки клиента, если он опенсорсный?
Так и не понял, почему State Machine не может быть вложенной ( и как следствие иметь глобальные переходы между состояниями) и почему невозможно параллельное выполнение состояний (даже не совсем понял, что это такое. Если к игровому объекту привязано 2 разных State Machine , можно ли считать это параллельным?) ?
Видимо, статья посвящена Unity, хотя не нашел в статье примеров использования ни того, ни другого, поэтому не могу точно сказать. Возможно, по списку хабов мне надо офильтровывать статьи, но хотелось бы в названии видеть, с чем имеем дело.
С абстрактной точки зрения, что SM, что дерево - оба графы, с разными свойствами. Не понимаю, почему один из них по древним заветам ситхов низведен до абсолюта НИКОГДА-не-использования.
Видимо просто ожидания не совпадают с реальностью. Подобный пост с Альфой или Сбером даже взгляда не зацепит, а от Тинькофф все еще по инерции ожидают "современного" и "инновационного" обслуживания без косяков и обманов.
в моей практике часто баловался с перечислениями в питоне: и наследовал, и записывал им в value объекты кастомных классов, динамически генерировал enum из справочника в БД и были попытки "магии" с
__set_name__...Безусловно, это дало нехилый буст в понимании работы многих аспектов работы питона, но сами наработки были в подавляющем числе нежнеспособны - пользоваться можно только копипастом уже используемых примеров, а последующие доработки новых механик несоизмеримо профиту усложняли код.
как итог - с enum теперь работаю исключительно как с набором литералов (максимум использую enum.IntEnum и enum.StrEnum) и сплю спокойно по ночам
Также (учитывая, что статья явно ссылается на Google Analytics) будет более корректным упомянуть, что Google отказывается от нескольких упомянутых в обзоре моделей атрибуции, в т.ч. от линейной и от атрибуции по первому клику (из-за чего нам под потребности клиента пришлось использовать опенсорсный счетчик).
Разнообразие выбора нам показали, но с ним и так сталкиваются все буквально первым же шагом, как касаются этой области. Будет классно дополнить статью продолжением с кейсами, сравнениями с разных точек зрения и соответствующими выводами. Ждем! Любые цифры и графики скажут больше, чем заранее известные прописные истины дижитал- (и не только) сфер "Одно (иногда) работает лучше другого" и "Чем больше факторов учтем, тем точнее будет прогноз".
[абсолютных утверждений вида "учитывая все факторы" также стоит избегать, иначе (откройте форточку) вам либо не поверят, либо попросят доказать утверждаемую всеобщность, из-за чего фокус внимания сместиться от того, что вы хотели донести.]
Надеюсь увидеть продолжение!
Хорошая статья на почитать вечерком! И было бы супер, если бы описание работы кода предшествовало самому коду. Ибо смотреть реализацию после объяснения - благое дело, а вот читать объяснение, после того как ты уже понял код - увы...
Аналогию понял, но тезис, в пользу которого Вы её используете, - нет. Мне правда интересно, что Вы имели ввиду, сможете поподробнее описать недостатки размышлений автора и чем плохо "всегда снимать" ?
Правильно ли понял, что автор утвержает истинность высказывания:
[ a*a = (c-b)*X ] => [ X = c+b ]?Довольно.... смело)