Да, действительно, но это ведь касается мутаций в половых клетках (гаметах) или при их формировании (мейоз). Только такие мутации переходят к потомкам и являются причиной эволюционных изменений. А мутации в остальных (соматических) клетках просто приносят страдания владельцу и теоретически можно было бы их избежать. Хотя вполне возможно, чего-то не учитываю.
Кстати, с развитием методов редактирования генома, человек выходит на скользкую тропинку борьбы с эволюцией, мутациями. К чему это приведёт, пока никто не знает, но явно очень сильно изменит человечество. Скорее всего, станет распространено планирование будущего ребёнка в аналоге магазина приложений или как создание героев в играх. Цвет глаз такой, рост такой, защита от таких-то болезней. Наиболее удачные конфигурации будут идти под лицензиями, но что-то будет и открытым. Фактически, клонирование на аналитическом уровне будет происходить. С существующими темпами лет через 15-30 вполне можно ожидать.
Всё правильно, но это React Dev Tools (я там в одном сообщении опечатался, имея в виду Redux Dev Tools). Это уже результат работы селекторов и просто свойства, переданные в конкретные React компоненты. В Redux Dev Tools только Redux state. Было бы удобнее видеть общую картину — состояние Redux state и всех зависимых от него селекторов, а не выискивать компоненты, где эти селекторы используются (они могут быть глубоко в дереве, генерироваться по условиям и т.д.), попутно бегая в код, чтобы смотреть какие селекторы в какие свойства мапятся.
Не совсем понимаю. Разве это противоречит тому, что я написал выше? Разумеется, для простейших приложений, которые не будут развиваться и не потребуют рефакторинга, можно завязаться жёстко на структуру стора. Но разве это можно назвать хорошим стилем? Да и далее в статье «you are encouraged to use selector functions, and to use the Reselect library for memoized selectors» и сама вся статья об этом: «we recommend using selectors to encapsulate the knowledge of where a given piece of state lives. Ideally, only your reducer functions and selectors should know the exact state structure, so if you change where some state lives, you would only need to update those two pieces of logic.»
Вы уверены? На данный момент селекторы — чужеродный для Redux элемент. Всё что я нашёл — вот это, где обсуждается необходимость данной фичи. Даже не представляю себе как бы Redux Devtools мог выводить информацию о селекторах без серьёзных изменений в способе их создания.
Кроме того, селекторы позволяют абстрагироваться от внутренней организации стора, упрощая последующий рефакторинг. Тут неплохо описано. Поэтому любые решения, где они идут отдельно от стора и без возможности их удобного мониторинга, выглядят несколько куцыми.
Это понятно, что мемоизация и сложные выборки — разные вещи, я же через «и» перечислил.
Стор хранит нормализованные данные, допустим, авторов и их книги с связями. Допустим, нам в разных компонентах надо считать число книг по авторам или выводить число книг, помеченных как новинка. Логично же сделать селектор, чтобы не повторять себя в каждом компоненте. Логично желание видеть значение этого селектора для отладки безотносительно того, в каком компоненте мы его используем. Это же свойство стора, одно из его расширенных представлений. Как view и процедуры в базе данных. Редьюсеры — как хранимые процедуры, меняющие стор. На данный момент не нашёл нормальных инструментов для решения этой задачи. Есть полузаброшенный проект для reselect, не позволяющий работать с большим числом селекторов, не выводящий их названия.
Простите, как же селекторы не являются часто используемой фичей? Что вообще можно использовать вместо них, чтобы не повторять себя при сложных выборках из стора и чтобы мемоизировать выборки? Даже в самом этом Redux Toolkit встроена библиотека reselect. И селекторы не модифицируют стор вообще-то, идут отдельно от него, хотя логичнее, чтобы всё было в комплекте, как с геттерами в Vuex.
Как-то всё очень разрозненно в этих конструкторах на Redux, даже официальных. Те же селекторы болтаются отдельно, аналога React Dev Tools для них нет, хотя по сути это варианты представления Redux Store, семантически относятся к нему, так же как и мутаторы — что синхронные, что асинхронные. Популярность этой библиотеки крайне низкая, как для официальной — 2200 звёзд в Git. Можно сравнить с альтернативными, более комплексными решениями: Mobx, easy-peasy, overmind (на который перешёл codesandbox).
В react/redux стеке очень не хватает единообразия. Буквально на каждом уровне (компоненты/общий стор) по-своему организовывается кэширование и отслеживание изменений, а также хранение состояния и вычислимых свойств на его основе. Часто с помощью инородных сторонних библиотек типа reselect. Аналогично и для изменений — синхронные мутации встроены, асинхронные — через сторонние библиотеки вроде Thunk или Saga. Столько всего нагородили, а способа увидеть состояние приложения в целом — нет.
Возможно, отсюда и вопрос. Я немного поизучал тему и нашёл описание системы Polys, разработанной, как оказалось, Лабораторией Касперского. Более того, обнаружился комментарий самого Касперского, который утверждает, что
это наша разработка Полис в «Московской упаковке». Наша собственная онлайн-голосовалка на блокчейне. Вышла на уровень Москвы — принимаю поздравления!
По поводу найденных уязвимостей пишет:
это херь полная. В тестовой демо-версии был короткий крипто-ключ, который было запланировано поменять перед «боевым» голосованием.
Из того, что прочитал о системе, там много интересных решений. Хотелось бы прояснения, действительно ли их система использовалась. По описанию не очень похоже.
Ожидаю от подобной системы в случае анонимного голосования следующих свойств:
— возможность голосующему убедиться, что его голос добавлен и добавлен правильно.
— невозможность никому кроме голосующего узнать, за кого голосовал кто-либо, кроме него.
— возможность любому убедиться в том, что в системе нет вброшенных голосов
Интересно, как вообще технически решить подобные задачи и можно ли?
Уже не совсем так. Эпигенетическое наследование чётко доказано для растений и беспозвоночных, а для млекопитающих ещё некоторые учёные упираются, но против фактов не попрёшь. Эпигенетические метки по идее должны стираться после оплодотворения и такой механизм есть, но как всегда спешили к релизу и работает он только на 99%.
Тут хорошо описано: learn.genetics.utah.edu/content/epigenetics/inheritance
Я тоже не являюсь специалистом, но из того, что было в нескольких курсах, сделал вывод, что «текст» генома не является единственным источником правды для формирования организма, даже если не брать в расчёт среду. Помимо него есть ещё и так называемые эпигенетические маркеры — особые метки (например, с помощью присоединения метильных групп к цитозину), которые блокируют или наоборот активируют соответствующий ген. Таким образом, можно иметь весь код генома, но не имея информации об этих метках невозможно предсказать все особенности организма. В сумме это называют эпигеномом. Когда-нибудь и его научатся сканировать, но там уже разная картина в разных видах клеток, насколько я понимаю. Собственно, само формирование разных тканей и происходит благодаря ему. И он тоже в какой-то степени наследуется.
Вообще, чем больше изучаешь механизмы эволюции видов и внутреннюю организацию клеток, тем больше осознание, что будь это программа, качество которой нужно оценить, ничего кроме «г… код» в голову бы не пришло. Тут тебе и смешение зон ответственности, и смешение данных и кода, куча грязных хаков, неоправданных усложнений и заброшенных частей. Алгоритмы работают плохо. Ну вот что стоило сделать абсолютно надёжный механизм контроля целостности ДНК? Нет, ничего подобного, постоянно возникают ошибки, ведущие к гибели и страданиям несчастных особей. Потому что до самих особей эволюции нет ни малейшего дела — это расходный материал. Особенно, если особь вышла из репродуктивного возраста. Для эволюции главное — видовое приспособление.
Даже за 160 евро. Но там не всё так просто. Насколько я понял, качество данных хуже, чем у компаний, выполняющих выборочное секвенирование. Вот тут www.beholdgenealogy.com/blog/?p=2879 и в следующих двух статьях энтузиаст, уже имеющий данные от пяти компаний, заказал ещё и полный геном, но оказалось, что данные хуже согласуются, не полные. Просто так их сконвертировать в формат, который бы поняли генеалогические сайты, не выйдет. Не знаю как с этим у Атласа.
Такой вариант тоже использовал, забыл уже. Нет, не вполне достаточно. Логически однотипные фрагменты хочется видеть расположенными на одном уровне всё-таки, во избежание ошибок. Иногда даже с принудительными отступами и отключением lint. Условие может быть не выделено в переменную, как тут, и тогда скобки всё равно появятся, усложняя восприятие.
Опциональные цепочки были бы очень полезны. Чего ещё мне часто не хватает — опционального добавления свойства в объект при его создании. Сейчас приходится извращаться, создавая объект без этого свойства, добавляя его отдельной строкой. Это размазывает логику, неудобно.
const data = {
prop1: 'prop1'
}
const condition = true
if (condition) {
data.prop2 = 'prop2
}
Тоже интересный проект, по юзабилити на высоте. Но фишка именно подобных описанному проектов в том, что создаётся собственный тезаурус известных слов и в каждом новом тексте ты обращаешь внимание только на те слова, которых не знаешь. При активном чтении их уже становится не очень много, чаще всплывают неизвестные значения или сочетания слов.
Отлично, что есть разработки в этом направлении. Самый, наверное, навороченный аналог — LingQ. Он платный (в бесплатном режиме практически ничего делать нельзя), но оттуда можно набрать идей. Там есть режим, когда после перехода на другую страницу все слова отмечаются как известные. Что-то подобное необходимо, если уровень не нулевой. Тыкать тысячи слов — непродуктивно. Ещё там есть возможность отмечать сочетания слов — необходимая вещь для фразовых глаголов и идиоматических выражений. Подключено много разных словарей плюс выводятся переводы других людей, что часто помогает. Там же и набор встроенных текстов есть, а также аудио, которое, к сожалению, никак не синхронизировано с текстом.
Да, я вот не понял как добавлять свой перевод (и можно ли). Ведь в английском у слов десятки значений и ты можешь знать слово в базовом значении, но встретить совершенно неожиданное альтернативное. В LingQ есть такая функция, но это приводило к другой проблеме, что везде это слово отмечено, как изучаемое, даже в известных значениях. Понятно, что на уровне текста распознать в каком значении оно встретилось невозможно. Не знаю, как решить эту проблему.
Другой момент, что такая система не учитывает формы слов. В английском это 2 формы для существительных, штуки 3-4 для глаголов. Но в турецком один корень может плодить сотни разных слов. Хорошо бы как-то это учитывать. Добавлять для изучения слово в основной форме, а в тексте понимать его в разных формах, причём желательно этим как-то давать юзеру управлять тоже. Скажем, я хочу всё-таки помечать формы неправильных глаголов (или неизученных времён турецкого).
Надеюсь, сервис будет развиваться. Очень не хватает такого.
Кстати, с развитием методов редактирования генома, человек выходит на скользкую тропинку борьбы с эволюцией, мутациями. К чему это приведёт, пока никто не знает, но явно очень сильно изменит человечество. Скорее всего, станет распространено планирование будущего ребёнка в аналоге магазина приложений или как создание героев в играх. Цвет глаз такой, рост такой, защита от таких-то болезней. Наиболее удачные конфигурации будут идти под лицензиями, но что-то будет и открытым. Фактически, клонирование на аналитическом уровне будет происходить. С существующими темпами лет через 15-30 вполне можно ожидать.
Стор хранит нормализованные данные, допустим, авторов и их книги с связями. Допустим, нам в разных компонентах надо считать число книг по авторам или выводить число книг, помеченных как новинка. Логично же сделать селектор, чтобы не повторять себя в каждом компоненте. Логично желание видеть значение этого селектора для отладки безотносительно того, в каком компоненте мы его используем. Это же свойство стора, одно из его расширенных представлений. Как view и процедуры в базе данных. Редьюсеры — как хранимые процедуры, меняющие стор. На данный момент не нашёл нормальных инструментов для решения этой задачи. Есть полузаброшенный проект для reselect, не позволяющий работать с большим числом селекторов, не выводящий их названия.
В react/redux стеке очень не хватает единообразия. Буквально на каждом уровне (компоненты/общий стор) по-своему организовывается кэширование и отслеживание изменений, а также хранение состояния и вычислимых свойств на его основе. Часто с помощью инородных сторонних библиотек типа reselect. Аналогично и для изменений — синхронные мутации встроены, асинхронные — через сторонние библиотеки вроде Thunk или Saga. Столько всего нагородили, а способа увидеть состояние приложения в целом — нет.
По поводу найденных уязвимостей пишет:
Из того, что прочитал о системе, там много интересных решений. Хотелось бы прояснения, действительно ли их система использовалась. По описанию не очень похоже.
— возможность голосующему убедиться, что его голос добавлен и добавлен правильно.
— невозможность никому кроме голосующего узнать, за кого голосовал кто-либо, кроме него.
— возможность любому убедиться в том, что в системе нет вброшенных голосов
Интересно, как вообще технически решить подобные задачи и можно ли?
Тут хорошо описано: learn.genetics.utah.edu/content/epigenetics/inheritance
Вообще, чем больше изучаешь механизмы эволюции видов и внутреннюю организацию клеток, тем больше осознание, что будь это программа, качество которой нужно оценить, ничего кроме «г… код» в голову бы не пришло. Тут тебе и смешение зон ответственности, и смешение данных и кода, куча грязных хаков, неоправданных усложнений и заброшенных частей. Алгоритмы работают плохо. Ну вот что стоило сделать абсолютно надёжный механизм контроля целостности ДНК? Нет, ничего подобного, постоянно возникают ошибки, ведущие к гибели и страданиям несчастных особей. Потому что до самих особей эволюции нет ни малейшего дела — это расходный материал. Особенно, если особь вышла из репродуктивного возраста. Для эволюции главное — видовое приспособление.
Можно, конечно, сделать вот так:
Но хотелось бы что-то более наглядное — ключи отдельно, значения отдельно и без ненужного обвеса. Например, как-то так:
Заодно и постфиксные условия ввести — они удобны иногда.
Да, я вот не понял как добавлять свой перевод (и можно ли). Ведь в английском у слов десятки значений и ты можешь знать слово в базовом значении, но встретить совершенно неожиданное альтернативное. В LingQ есть такая функция, но это приводило к другой проблеме, что везде это слово отмечено, как изучаемое, даже в известных значениях. Понятно, что на уровне текста распознать в каком значении оно встретилось невозможно. Не знаю, как решить эту проблему.
Другой момент, что такая система не учитывает формы слов. В английском это 2 формы для существительных, штуки 3-4 для глаголов. Но в турецком один корень может плодить сотни разных слов. Хорошо бы как-то это учитывать. Добавлять для изучения слово в основной форме, а в тексте понимать его в разных формах, причём желательно этим как-то давать юзеру управлять тоже. Скажем, я хочу всё-таки помечать формы неправильных глаголов (или неизученных времён турецкого).
Надеюсь, сервис будет развиваться. Очень не хватает такого.