Из вещей, требующих улучшения: сейчас есть оверхед с адаптерами для компонентов. Для условного компонента Table требуется адаптер, чтобы соединить его (компонент) со слоем DSL. Опираясь на текущий опыт, это кажется избыточным. Работаем над упрощением.
Если я прально понял проблему - REST+JSON - много головняка, стандартов, писанины. Если закрыть более простым и менее гемморойным протоколом чем html/xml, то возможно, муры писать будем меньше. Такой протокол/решение есть - https://github.com/Claus1/unigui
Provide a programming technology that does not require front-end programming, for a server written in any language, for displaying on any device, in any resolution, without any tuning.
Есть технология, даже мол не нужен. шлем дынные с сервера на любом языке - получаем GUI автоматом + оповещения что пользователь делает с данными. https://github.com/Claus1/unigui Можно вообще всех фронтеров уволить, но по сути, никому (кроме 2-5) не нужна. слишком непонятная..
Если количество элементов, которые мы добавляем слайс, не будет превышать len, вернется новый слайс, который ссылается на тот же базовый массив, что и предыдущий слайс.
len - текущая длинна. при добавлении не будет привышена только если ничего не добавляем. но.. это верно для cap.
"случайно распределенные точки, размещенные на поверхности сферы, почти все находятся на расстоянии полного диаметра друг от друга." Что за фигня? "Наш крокодил, как хотим, так и меряем".
не-е-е. Я обратил внимание на неадекватность цифр по доходам/желаемым инвестициям. вы же говорите что булочник может и триллион сделать на булках. не может. в булках нет ноу-хау в отличие от Теслы. и сравнивать их наивно и не корректно.
Не убеждает? "Количество пользователей с платной подпиской выросло на 20 тыс. до 130 тыс.пользователей." сумма дохода 300 лям. с одного носа 2 тыщ$ по минимуму берут. че, норм. если на сотую часть поверил, пошел бы пилить рисовалки диаграмм.
Зачем они просят интестиции при доходе в 300 лямов. все спускают на спорткары или лохматят толстых дядей? как при доходе 300 лямов компания может стоить 17 лярдов. если допустить что у них 0 затраты и 300 лямов - чистая прибыль, стоимость компании при доходности на акции 10% == 3 лярда. понятно что все это туфта, но зачем тут такое писать , мы ж тут не интесторы, 2 на 2 умножить могём. и как рисовалка диаграм может стоить столько. ей-богу смешные.
Зачем сериализовать компонент, если можно сериализовать данные и отрисовать их компонентом, указав его тип. где логика? пример правильного подхода и для всех серверных языков - https://github.com/Claus1/unigui
можно посмотреть как это решено здесь https://github.com/Claus1/unigui . заодно узнать о протоколе.
Если я прально понял проблему - REST+JSON - много головняка, стандартов, писанины. Если закрыть более простым и менее гемморойным протоколом чем html/xml, то возможно, муры писать будем меньше. Такой протокол/решение есть - https://github.com/Claus1/unigui
есть более хитрый python фреймворк , для которого не надо знать flutter/Vue/.. - дизайнит автоматом из данных. https://github.com/Claus1/unigui
https://github.com/Claus1/unigui оперирует напрямую данными-типами для визуализации.
Provide a programming technology that does not require front-end programming, for a server written in any language, for displaying on any device, in any resolution, without any tuning.
Есть технология, даже мол не нужен. шлем дынные с сервера на любом языке - получаем GUI автоматом + оповещения что пользователь делает с данными. https://github.com/Claus1/unigui Можно вообще всех фронтеров уволить, но по сути, никому (кроме 2-5) не нужна. слишком непонятная..
Вроде и к монге прикрутили временные ряды. Есть ли другой смысл в RavenDb в сравнении с монгой?
len - текущая длинна. при добавлении не будет привышена только если ничего не добавляем. но.. это верно для cap.
DisplayLCD 1832 x 1920 per eye @ 120 Hz[2]
"случайно распределенные точки, размещенные на поверхности сферы, почти все находятся на расстоянии полного диаметра друг от друга." Что за фигня? "Наш крокодил, как хотим, так и меряем".
"C одного КЛИЕНТА." скорее посчитали поголовно. иначе порядок цифр был бы другой.
"Какие ноу-хау были у Uber или AirBnb?" бизнес ноу-хау и тех. ноу-хау - вещи несравнимые. первые любой дурак может при должном везении.
не-е-е. Я обратил внимание на неадекватность цифр по доходам/желаемым инвестициям. вы же говорите что булочник может и триллион сделать на булках. не может. в булках нет ноу-хау в отличие от Теслы. и сравнивать их наивно и не корректно.
Не убеждает? "Количество пользователей с платной подпиской выросло на 20 тыс. до 130 тыс.пользователей." сумма дохода 300 лям. с одного носа 2 тыщ$ по минимуму берут. че, норм. если на сотую часть поверил, пошел бы пилить рисовалки диаграмм.
Написал если, чтобы посчитать максимум стоимости.
Зачем они просят интестиции при доходе в 300 лямов. все спускают на спорткары или лохматят толстых дядей? как при доходе 300 лямов компания может стоить 17 лярдов. если допустить что у них 0 затраты и 300 лямов - чистая прибыль, стоимость компании при доходности на акции 10% == 3 лярда. понятно что все это туфта, но зачем тут такое писать , мы ж тут не интесторы, 2 на 2 умножить могём. и как рисовалка диаграм может стоить столько. ей-богу смешные.
Зачем попу гармонь и геморой (Django, его темплейты, python, и прочее,) если можно больше и без них и на любом языке. https://github.com/Claus1/unigui
Вот google Jax есть же. он самый быстрый вроде и всеядный . +TPU
не. это жуть.
Зачем сериализовать компонент, если можно сериализовать данные и отрисовать их компонентом, указав его тип. где логика? пример правильного подхода и для всех серверных языков - https://github.com/Claus1/unigui
Если dash кажется простым и удобным, то возможно большое удивление на фоне https://github.com/Claus1/unigui
Интересная статья, но большая сильно)
есть похожее https://aliexpress.ru/item/2016949030.html?spm=a2g0o.productlist.0.0.2ebd3cb7nrp1Sj&algo_pvid=e80241b9-56d1-4996-a1bb-590e45d3f327&algo_expid=e80241b9-56d1-4996-a1bb-590e45d3f327-45&btsid=0b8b15ea16327458170836418ee1a4&ws_ab_test=searchweb0_0,searchweb201602_,searchweb201603_