Возможно, для задачи сбора метрик лучше бы подошла time series database, а не rdbms. Разные типы баз данных предлагают разные модели работы с этим самыми данными, что отражается и в языках запросов.
А то почему бы матрицы не "умножать" по рабоче-крестьянски типа
Тогда бы умножение матриц стало коммутативным и доступным для понимания даже школьникам начальных классов. Преподаватели в универах останутся без работы.
не продать, даже по заниженной цене, а отказаться, чтобы сохранить за собой хоть что-то
Сокрее он не может официально продать что-либо айтишное РФ, не нарушая при этом условий санкций, наложенной страной где сейчас живёт - такая сделка автоматически поставит его вне закона. Поэтому публичные условия формулируют в таких терминах. Если кто-то напишет как там все было на самом деле, это будет прям новость-новость.
Интересно как они распилят внутреннюю инфраструктуру на две компании, используемую для разработки, которая насколько мне известно, всегда была централизованной.
Есть два способа синхронизировать между собой разные штуки: хореография и оркестрация.
В первом случае они подталкивают друг дружку за колбеки, пока не придут в состояние взаимного равновесия. Первая скроллится, вторая перемещается и тянет за собой первую, которая... Если обратных связей не много, то прием вполне рабочий. Но когда их становится больше, то разобраться в такой толкучке станет нереально. Приятной отладки.
Лучше сделать посредника, который будет слушать всех их хотелки ивенты, и потом решать какое состояние в итоге должно получиться. В конце все хором рендерятся в соответствии с полученными вводными и по новой. По крайней мере у вас будет больше контроля.
Узкое место это обмен данными между DOM и рантаймом JavaScript. DOM API в основном синхронный и заставляет ждать результатов. К тому же браузеру приходится перепаковывать структуры данных из одного формата в другой. vDOM помогает производить максимум вычислений в пределах JS и лишь иногда синхронизироваться с настоящим DOM (может раз в 16ms или даже чаще, но это все равно не так часто как если ходить за каждым атрибутом по сто раз в DOM и обратно). При попытке вынести расчет vDOM в воркер узким местом может стать коммуникация с основным потоком. Но там есть четкая зависимость от объема данных.
Практически во всех областях IT-разработки весь мир перешел на использование многопоточности: мобильные приложения, бэкенд, прикладное программирование
Про это есть старый доклад на тему Concurrency , который однако до сих пор актуален. Если коротко: многопоточность это для персоналок, в игры гонять, ну или там рисовать юай. Для бекендов она не слишком полезна: для них типичны либо задачи, которые прекрасно решаются в один поток на одном ядре, либо требующие масштабирования за пределы одной машинки.
Если это часть их внутренней ППР (политическо-просветителькой работы, ну или как ещё раньше говорили - посидели, поговорили, разошлись), то новость на их собственном сайте об таком событии вполне уместна.
Но какой эффект это оказало снаружи, в чем состоит общественная значимость проделанной ими работы? Если эффекта ноль, то пока тут не чего ни критиковать, ни поддерживать.
Тогда либо остается либо просто критиковать, что все не так, либо что-то предлагать.
Можно просто брать и делать руками без лишнего популизма ртом. А люди потом оценят работу по практическим эффектам и результатам. Вот тогда уже и выходить на публику собирать свои лайки.
Мне кажется люди стали с недоверием относиться даже к здавым идем из-за того, что они регулярно превращаются в фиговый лист на этапах реализации, где фактические исполнители и бенефициары под их перекрытием потом творят что-то нездоровое.
Так сложилось, что айти развивается на английском. Там связи между теорией CS и практикой, выраженной в конкретных языках программирования, благодаря общей терминологии выглядят довольно очевидными и само собой разумеющимися.
На русском оригинального - капля в море. Обычно это переводы, они вторичны и нередко содержат ошибки, которые переводчики однако выдают за креатив и оригинальность мысли. Где-то заменены слова, где-то пропущены детали, где-то иначе расставлены акценты и выделены какие-то несущественные детали вместо важного, добавлена эмоциональная окраска и т.п. Часто вставляют собственные трактовки, ассоциации и философию. Получается как кривое зеркало - где-то более, где-то менее - но как результат разобраться что к чему в этих отражениях гораздо сложнее. Что касается CS, я не очень доверяю Вики на русском, и стараюсь перепроверять.
Вопреки расхожему мнению, декларативные языки описывают на самом деле не "результат", а некоторую семантическую структуру. И эта структура может быть использована для программного анализа с получением множества разных "результатов" в зависимости от потребностей
Что бы там ни говорили адепты
функционального программирования, но оно ни в коем разе не является декларативным. ФП - это просто императивное программирование на иммутабельных структурах, описывающее конкретные действия, по трансформации заданных входных параметров в заданные выходные. Всё, что можно сделать с чистой функцией - это её исполнить
Ваши трактовки отличаются от классических. Я не говорю, что вы не правы, просто непривычно.
Обычно говорят о трёх категориях моделей вычисления: https://en.m.wikipedia.org/wiki/Model_of_computation - последовательные, функциональные и конкурентные. Они используются при анализе алгоритмов и дают инсайты разработчикам языков программирования.
Языки программирования задают грамматику/синтаксис и модель исполненияhttps://en.m.wikipedia.org/wiki/Execution_model. Условно, это то, что представляет себе разработчик, читая программу - как она будет исполняться.
Получается, что алгоритм составляется в логике модели вычисления, а записываться с учётом модели исполнения выбранного языка.
Декларативное программирование https://en.m.wikipedia.org/wiki/Declarative_programming это стиль, когда конструкции в программе выражают чисто логику вычисления (фактически что было в исходном алгоритме), без описания потока исполнения (т.е. как посчитать).
Например, если мы говорим, что "в списке есть элемент foo и элемент bar", то декларативной можно трактовать запись:
Мы отклоняется от декларативности в ситуациях когда язык не позволяет выразить алгоритм в своих терминах, либо мы сами выбираем для него иные выразительные средства. Это может делаться сознательно, например с целью оптимизации, либо безосновательно.
За пределами алгоритма, ни какой другой семантики декларативный стиль не рассматривает. Все остальные интерпретации это уже область наших оценочных суждений, а не программирование.
Моделей вычислений, которые относят к ФП несколько. У большинства ноги растут из математики. В популярной lambda calculus программа составляется как композиция функций (f.g) и так далее. Данные здесь вещь вторичная, как вам неважно при записи математикой формы X там или Y. Есть даже point-free style, где сам агрумент функции ни разу упоминается. Вычислять все это можно, например, как редукцию функции (упрощение, переписыванием из одной формы в другую, как на уроках матана).
В JS мы в самом деле вынуждены использовать императивые конструкции когда пишем в стиле ФП. Но это вынужденное отклонение от декларативности, из-за ограничений модели вычисления в этом языке, а не свойство исходной модели вычисления. В том же Haskell картинка ровно наоборот - ФП как родной, а императивность и энергичность приходится костылить.
а в тесте создаются императивно и без таких вот пропертей:
const view = new NotesList
view.notes().make( 'foo' )
view.notes().make( 'bar' )
const dom = view.render()
Уверен, что связь там наверняка тривиальная. Но все равно не покидает ощущение, что тест тестит что-то другое. Можете добавить пример теста с jsx (или объяснить почему так делать не стоит если у вас другое мнение)?
Форматирование текста перед отправкой нужно готовить самому - он ведь только переводчик, а не угадыватель грамматики и пунктуации. Куски разделенные переносами строк воспринимает как разные фрагменты.
У бесплатного Google Translate API было ограничение на количество запросов. До некоторой степени решалось с помощью пула проксей или тор. Сервис из этого не сделать, но для мелко-домашнего применения годилось.
Обычно так и поступают - отправляют в отдельный процесс и периодически перезапускают.
Кстати в MacOS функция распознавания текста на картинках уже примерно год как встроена в стандартный просмоторщик. Аналогично работает в браузере и некоторых других приложениях. Выглядит так, что при выделении мышкой области на изображении она выделяется как обычный текст. Иногда на сайтах уже не понятно где текст текстом, а где картинкой.
На самом деле интересно, хоть и неожиданно. Любую задачу можно решить разными способами и разница в виде diff выглядит наглядно.
Для полноты картины не хватает модульных тестов и какого-нибудь сторибука. Они хорошо, как лакмусовая бумажка, показывают из каких соображений и насколько хорошо тот или иной подход позволил декомпозировать код (или же получилась красиво приготовленная лапша, где все зависит от всего).
Нам приходится постоянно тащить за собой в компонент useStore, и чем больше данных вам нужно - тем сильнее разрастается компонент, и это мы еще даже не обрабатываем данные...
Давайте перейдем к первому этапу - воспользуемся reflect.
Реакт постоянно тянет вывернуться на изнанку и обернуться в мир фантазий с элементами функционального программирования. Но его все равно оттуда достают. Помните HOC, mapStateToProps, а потом нет - хуки?
Effector крутой фреймворк, но то, о чем вы рассказываете в данной публикации - спорно.
В реакте принято выражать композицию компонентов с помощью вложенности тегов друг в друга. Да, все то же самое можно делать и другими способами - чисто технически это может быть даже проще, - но это противоречит главному принципу.
Композируя компоненты не через другие компоненты, а, допустим, через данные, вы делаете рендеринг в целом зависимым от каких-то сторонних, ни как не контролируемых реактом факторов. Это довольно быстро начинает выходить боком в поддержке. Начиная с невнятных стектрейсов и вплоть до трудно решаемых проблем с перфомансом из-за того что компоненты прорастают из данных когда угодно.
поэтому жалко тратить время синхронистов на уборку бассейна:)))
Классная метафора. :) Просто так не бывает. Бывает так, что у вас нет отдельного вечно-бесплатного ресурса ни на уборку, ни на ремонт бассейна. Все сами. Сами все делаем, сами выступаем, сами иногда обделываемся (физиология, пресловутый человеческий фактор) и сами же потом чиним и убираем. Ну или откладываем уборку с починкой в беклог задач за которые нам ни кто ни когда не заплатит. А пока пытаемся производить на публику тот же эффект, делая те же фигуры, но уже в немножко мутной и слегка попахивающей воде, под чуть-чуть протекающей крышей. Публика негодует и отказывается платить. Мы признаем ошибки на ретро и обещаем в следующем спринте показать ещё больше трюков, занырнув вообще на самую глубину)).
Разработка ещё похожа на дженгу, только наоборот: мы строим башню, добавляя кубики разного размера (M, L, XXL, вот это вот все) до тех пор, пока она не развалится. Ну и если на начальных этапах стройка идёт быстро потому, что кубики, даже самые огромные, встают просто на ровный стол, то дальше у них появляются зависимости, когда их приходится ставить уже друг на дружку. Маленькие на большие, большие на маленькие. Хорошо если у всех был четкий план и кубики на нижних ярусах стоят ровно и надёжно. Но нередко бывает, что кто-то поспешил все успеть и поставил свой маленький кубик немножко криво, или не убрал за собой лишнее. Таким образом у новой смены прибавляется немножко работы и эстимации даже для самых простых задач начинают плыть в далёкие края.
А бывают моменты, что очередной точно такой же кубик нужно запихнуть в середину. Ну вот так получилось. То есть для этого надо теперь или пересобрать половину башни, или нагородить каких-то ацких подпорок. И тогда объем работы увеличивается уже не на немножко, а может и ни в какой бюджет.
В общем, я это к чему. Планы ни что, планирование - все. И сокращать на это время - правильно. Но кажущиеся на первый взгляд размеры кубиков это лишь пол беды. Многое зависит от архитектуры и согласованности работы команд. Если пытаться заменить всем этим планированием и проектирование, то вы просто сократите время до катастрофы).
Возможно, для задачи сбора метрик лучше бы подошла time series database, а не rdbms. Разные типы баз данных предлагают разные модели работы с этим самыми данными, что отражается и в языках запросов.
Вряд-ли вы имели ввиду разработку программного обеспечения с открытыми исходниками.
Тогда бы умножение матриц стало коммутативным и доступным для понимания даже школьникам начальных классов. Преподаватели в универах останутся без работы.
Да, интересно как много тут людей, у которых все эти ссылки подсвечены фиолетовым?
Сокрее он не может официально продать что-либо айтишное РФ, не нарушая при этом условий санкций, наложенной страной где сейчас живёт - такая сделка автоматически поставит его вне закона. Поэтому публичные условия формулируют в таких терминах. Если кто-то напишет как там все было на самом деле, это будет прям новость-новость.
Интересно как они распилят внутреннюю инфраструктуру на две компании, используемую для разработки, которая насколько мне известно, всегда была централизованной.
Есть два способа синхронизировать между собой разные штуки: хореография и оркестрация.
В первом случае они подталкивают друг дружку
за колбеки, пока не придут в состояние взаимного равновесия. Первая скроллится, вторая перемещается и тянет за собой первую, которая... Если обратных связей не много, то прием вполне рабочий. Но когда их становится больше, то разобраться в такой толкучке станет нереально. Приятной отладки.Лучше сделать посредника, который будет слушать всех их
хотелкиивенты, и потом решать какое состояние в итоге должно получиться. В конце все хором рендерятся в соответствии с полученными вводными и по новой. По крайней мере у вас будет больше контроля.Узкое место это обмен данными между DOM и рантаймом JavaScript. DOM API в основном синхронный и заставляет ждать результатов. К тому же браузеру приходится перепаковывать структуры данных из одного формата в другой. vDOM помогает производить максимум вычислений в пределах JS и лишь иногда синхронизироваться с настоящим DOM (может раз в 16ms или даже чаще, но это все равно не так часто как если ходить за каждым атрибутом по сто раз в DOM и обратно). При попытке вынести расчет vDOM в воркер узким местом может стать коммуникация с основным потоком. Но там есть четкая зависимость от объема данных.
Про это есть старый доклад на тему Concurrency , который однако до сих пор актуален. Если коротко: многопоточность это для персоналок, в игры гонять, ну или там рисовать юай. Для бекендов она не слишком полезна: для них типичны либо задачи, которые прекрасно решаются в один поток на одном ядре, либо требующие масштабирования за пределы одной машинки.
Если это часть их внутренней ППР (политическо-просветителькой работы, ну или как ещё раньше говорили - посидели, поговорили, разошлись), то новость на их собственном сайте об таком событии вполне уместна.
Но какой эффект это оказало снаружи, в чем состоит общественная значимость проделанной ими работы? Если эффекта ноль, то пока тут не чего ни критиковать, ни поддерживать.
Можно просто брать и делать руками без лишнего популизма ртом. А люди потом оценят работу по практическим эффектам и результатам. Вот тогда уже и выходить на публику собирать свои лайки.
Мне кажется люди стали с недоверием относиться даже к здавым идем из-за того, что они регулярно превращаются в фиговый лист на этапах реализации, где фактические исполнители и бенефициары под их перекрытием потом творят что-то нездоровое.
Вертолет перемещает на большие расстояния, а ловить сантиметры на месте - обычным краном.
Так сложилось, что айти развивается на английском. Там связи между теорией CS и практикой, выраженной в конкретных языках программирования, благодаря общей терминологии выглядят довольно очевидными и само собой разумеющимися.
На русском оригинального - капля в море. Обычно это переводы, они вторичны и нередко содержат ошибки, которые переводчики однако выдают за креатив и оригинальность мысли. Где-то заменены слова, где-то пропущены детали, где-то иначе расставлены акценты и выделены какие-то несущественные детали вместо важного, добавлена эмоциональная окраска и т.п. Часто вставляют собственные трактовки, ассоциации и философию. Получается как кривое зеркало - где-то более, где-то менее - но как результат разобраться что к чему в этих отражениях гораздо сложнее. Что касается CS, я не очень доверяю Вики на русском, и стараюсь перепроверять.
Ваши трактовки отличаются от классических. Я не говорю, что вы не правы, просто непривычно.
Обычно говорят о трёх категориях моделей вычисления: https://en.m.wikipedia.org/wiki/Model_of_computation - последовательные, функциональные и конкурентные. Они используются при анализе алгоритмов и дают инсайты разработчикам языков программирования.
Языки программирования задают грамматику/синтаксис и модель исполнения https://en.m.wikipedia.org/wiki/Execution_model. Условно, это то, что представляет себе разработчик, читая программу - как она будет исполняться.
Получается, что алгоритм составляется в логике модели вычисления, а записываться с учётом модели исполнения выбранного языка.
Декларативное программирование https://en.m.wikipedia.org/wiki/Declarative_programming это стиль, когда конструкции в программе выражают чисто логику вычисления (фактически что было в исходном алгоритме), без описания потока исполнения (т.е. как посчитать).
Например, если мы говорим, что "в списке есть элемент foo и элемент bar", то декларативной можно трактовать запись:
Если алгоритм был бы задан иначе: "в пустой список добавили элемент foo, а потом - bar" - тогда декларативной будет вот такая запись:
Мы отклоняется от декларативности в ситуациях когда язык не позволяет выразить алгоритм в своих терминах, либо мы сами выбираем для него иные выразительные средства. Это может делаться сознательно, например с целью оптимизации, либо безосновательно.
За пределами алгоритма, ни какой другой семантики декларативный стиль не рассматривает. Все остальные интерпретации это уже область наших оценочных суждений, а не программирование.
Моделей вычислений, которые относят к ФП несколько. У большинства ноги растут из математики. В популярной lambda calculus программа составляется как композиция функций (f.g) и так далее. Данные здесь вещь вторичная, как вам неважно при записи математикой формы X там или Y. Есть даже point-free style, где сам агрумент функции ни разу упоминается. Вычислять все это можно, например, как редукцию функции (упрощение, переписыванием из одной формы в другую, как на уроках матана).
В JS мы в самом деле вынуждены использовать императивые конструкции когда пишем в стиле ФП. Но это вынужденное отклонение от декларативности, из-за ограничений модели вычисления в этом языке, а не свойство исходной модели вычисления. В том же Haskell картинка ровно наоборот - ФП как родной, а императивность и энергичность приходится костылить.
Чистенько :) Только один вопрос. В приложении компоненты используется декларативно:
а в тесте создаются императивно и без таких вот пропертей:
Уверен, что связь там наверняка тривиальная. Но все равно не покидает ощущение, что тест тестит что-то другое. Можете добавить пример теста с jsx (или объяснить почему так делать не стоит если у вас другое мнение)?
Форматирование текста перед отправкой нужно готовить самому - он ведь только переводчик, а не угадыватель грамматики и пунктуации. Куски разделенные переносами строк воспринимает как разные фрагменты.
У бесплатного Google Translate API было ограничение на количество запросов. До некоторой степени решалось с помощью пула проксей или тор. Сервис из этого не сделать, но для мелко-домашнего применения годилось.
Обычно так и поступают - отправляют в отдельный процесс и периодически перезапускают.
Кстати в MacOS функция распознавания текста на картинках уже примерно год как встроена в стандартный просмоторщик. Аналогично работает в браузере и некоторых других приложениях. Выглядит так, что при выделении мышкой области на изображении она выделяется как обычный текст. Иногда на сайтах уже не понятно где текст текстом, а где картинкой.
На самом деле интересно, хоть и неожиданно. Любую задачу можно решить разными способами и разница в виде diff выглядит наглядно.
Для полноты картины не хватает модульных тестов и какого-нибудь сторибука. Они хорошо, как лакмусовая бумажка, показывают из каких соображений и насколько хорошо тот или иной подход позволил декомпозировать код (или же получилась красиво приготовленная лапша, где все зависит от всего).
Реакт постоянно тянет вывернуться на изнанку и обернуться в мир фантазий с элементами функционального программирования. Но его все равно оттуда достают. Помните HOC, mapStateToProps, а потом нет - хуки?
Effector крутой фреймворк, но то, о чем вы рассказываете в данной публикации - спорно.
В реакте принято выражать композицию компонентов с помощью вложенности тегов друг в друга. Да, все то же самое можно делать и другими способами - чисто технически это может быть даже проще, - но это противоречит главному принципу.
Композируя компоненты не через другие компоненты, а, допустим, через данные, вы делаете рендеринг в целом зависимым от каких-то сторонних, ни как не контролируемых реактом факторов. Это довольно быстро начинает выходить боком в поддержке. Начиная с невнятных стектрейсов и вплоть до трудно решаемых проблем с перфомансом из-за того что компоненты прорастают из данных когда угодно.
Классная метафора. :) Просто так не бывает. Бывает так, что у вас нет отдельного
вечно-бесплатногоресурса ни на уборку, ни на ремонт бассейна. Все сами. Сами все делаем, сами выступаем, сами иногда обделываемся (физиология, пресловутый человеческий фактор) и сами же потом чиним и убираем. Ну или откладываем уборку с починкой в беклог задачза которые нам ни кто ни когда не заплатит. А пока пытаемся производить на публику тот же эффект, делая те же фигуры, но уже в немножко мутной и слегка попахивающей воде, под чуть-чуть протекающей крышей. Публика негодует и отказывается платить. Мы признаем ошибки на ретро и обещаем в следующем спринте показать ещё больше трюков, занырнув вообще на самую глубину)).Разработка ещё похожа на дженгу, только наоборот: мы строим башню, добавляя кубики разного размера (M, L, XXL, вот это вот все)
до тех пор, пока она не развалится. Ну и если на начальных этапах стройка идёт быстро потому, что кубики, даже самые огромные, встают просто на ровный стол, то дальше у них появляются зависимости, когда их приходится ставить уже друг на дружку. Маленькие на большие, большие на маленькие. Хорошо если у всех был четкий план и кубики на нижних ярусах стоят ровно и надёжно. Но нередко бывает, что кто-то поспешил все успеть и поставил свой маленький кубик немножко криво, или не убрал за собой лишнее. Таким образом у новой смены прибавляется немножко работы и эстимации даже для самых простых задач начинают плыть в далёкие края.А бывают моменты, что очередной точно такой же кубик нужно запихнуть в середину. Ну вот так получилось. То есть для этого надо теперь или пересобрать половину башни, или нагородить каких-то ацких подпорок. И тогда объем работы увеличивается уже не на немножко, а может и ни в какой бюджет.
В общем, я это к чему. Планы ни что, планирование - все. И сокращать на это время - правильно. Но
кажущиеся на первый взглядразмеры кубиков это лишь пол беды. Многое зависит от архитектуры и согласованности работы команд. Если пытаться заменить всем этим планированием и проектирование, то вы просто сократите время до катастрофы).