В принципі згоден, там нескладний однорядковий фікс
github.com/...​abb16c2aa0b33dbcd442d50d5

Fixed + Deployed =)

= ))) не баг, фіча

Fixed + Deployed.
Дякую за відгук. Дійсно, числа можуть бути довші за 20 символів :)

GPT )))
Те, що ти кажеш, дуже цікаве і підкреслює важливу особливість людського інтелекту — його унікальність і варіативність. Навіть якщо створити суперсильний ШІ, який перевершить людський інтелект у багатьох сферах, його стандартизація як єдиної моделі не здатна замінити всю різноманітність людських мізків. Кожна людина має свій унікальний досвід, контекст, сприйняття та стиль мислення.

Це дає змогу навіть тим, хто не є експертами або «найрозумнішими», знаходити унікальні рішення, що ШІ не може передбачити, оскільки його навчання обмежене даними та моделями, на яких він був тренований. Саме в цьому різнобічність людства стає перевагою — у здатності адаптуватися, мислити нелінійно та інколи знаходити відповіді в тих місцях, де цього не очікують.

ШІ, звісно, може перевершити людство в питаннях, де потрібна величезна кількість даних чи швидкі обчислення. Але різноманітність людського мислення — це саме те, що робить нас унікальними і створює невичерпні можливості для розвитку, навіть там, де ШІ може бути дуже сильним.

Як ти вважаєш, чи варто розвивати більше різноманітних моделей ШІ для підтримки цієї варіативності, чи все ж таки краще зосередитися на одній надпотужній моделі?

Альтман трохи помиляється.
Уявімо суперсильний ШІ вже існує, його розтиражували. Але це лише одна навчена модель. А у людей 8 млрд мізків і кожен навчався і розвинувся трошки по іншому. Як казав колись Черчиль, величехний урок життя, що і дурні іноді бувають праві. Тобто найрозумніший ШІ не зможе повторити всю варіатативність біологічних видів. Або навчити мільярд моделей різними алгоритмами і всеодно не буде гарантії, що якась людина не виявиться розумніше в якомусь специфічному питанні.

Не тільки для навчання. Поставив вчора ollama з 70b параметрів. На моєму TnhinkPad 32gb iCore 7 одну відповідь «думало» кілька годин.
А там ще є моделька на 200b параметрів ... і це ніразу не супер AI.

Не закрився, все Ок =)

Проєкт живий. Додав першу інтеграцію с ШІ

Тепер по простому промпту:

«Create web app where I can find list of most popular youtube videos with amount of views. Add link to youtube.»
або
«List of popular Ukraine restaurants with their gps coordinates»

Створюється за 10-15 сек багатосторінковий веб апп з стандартним (поки що) інтерфейсом

Потестувати можна тут:
fraplat.com/...​iter/AIToWebApp/Dashboard

Сам ШІ конструктор + Апп Стор на мінімалках, написано на самому ж ФП приблизно в 100 рядків коду.
github.com/...​s/Applications/AIToWebApp

Загальна кількість проєктів на ФП перевищила 43
fraplat.com/jupiter/ListOfProjects

Загальна стратегія розвитку зараз така.
ФП дійсно дає змогу писати в надцять разів меньше коду майже на весь спектр прикладних задач.
ФП + ШІ, дорівнює інструмент, який пише легко читаємий/модифікуємий код людиною з набагато меньшою кількістю помилок, оскільки інші мови програмування\фреймворки для сучасного ШІ доволі складні.

Є багато інших новин, але це, мабуть, буде інша стаття на доу.
Також в нас зявився тг канал: https:\\t.me\fraplat

Досі не розумію, як вони зібрались вирішити цю задачу.
В інтернеті є петабайти англійскього тексту і навіть прімитивними алгоритмами можна навчити машину розуміти той текст. Тому що він однозначний і його дуже багато, на всі випадки життя. А от в програмуванні на кожну з мов нема петабайт тексту. Більш того, ті гігабайти розділені на фреймворки, кожен з котрих може бути повною шизою чергових абстракцій. Нема в них тих обємів для навчання.
Тож програмувати щось набагато складніше пінг-понга, який скоріш за все ШІ зкопіював десь з гітхабу, наврядчи зможе в найближчій перспективі.

від чого збивається scroll position

Це я виправив, скрол тепер не збивається.
Доречі дякую за фідбек, цю штуку давно хотів виправити,
тож фідбек був гарний аргумент зробити це зараз.
Код мінявся на рівні платформи, тож всі існуючи проєкти на платформі
отримали це виправлення автоматично.

лайки не ставить, коментарі не відправляються

Я це зробив, аккаунт «Testing»

Доречі, цей баг щойно виправив.

Мене все частіше дивує платформа. Буває за звичкою ниряєш десь під капот, дебажити складну внутрішню логіку платформи, думаєш що там щось зламали останні коміти, а потім розумієш, що все що потрібно було .... підправити джисон.
Сказати що юзер з ролю User, має право писати в масив Likes в Security dimension.
І це все.

"Likes": {
        "Allow": {
          "Write": [
            "User"
          ]
        },

github.com/...​adc167074bf0cff457e6eb28e

Схоже саме і так буде виглядати справжнє програмування майбутнього.
Кілька сотень рядків красивого функціонального коду, плюс конфігурація бд в джисонах і складний сайт працює.

Це я до того що кеш це добре, але лише там де він потрібний, якщо в нас немає проблеми з швидкістю відкриття аккаунта користувача то для чого його кешувати?

Там весь сайт, наче мене зновую підєднали до модему dial up який пакети передає через аналоговий телефон зі швідкістю 33,6 кбіт/сек. Ні одна сторінка не відкривається швидко.

Майже 3 секунди на завантаження сторінки. Мабуть ми маємо на увазі якісь різні кеші.
fraplat.com/...​143a1bce64d2ef2001029.png
Ваш кеш бігає на Плутон і назад, схоже.

Дякую звичайно за аналіз нашої аудиторії та бази даних, але чому тоді 10% самих активних, чому не 90% самих пасивних які не міняються?

То треба трохи в Computer Science, чому саме так. Теорія ймовірності.
Розподіл Парето. І оце ось все.

А кейс коли людина відправляє коментар більше ніж 255 символів теж ігноруємо? Пароль до 6 символів чи до 8? Писав би я веб апп для програмістів то можливо б і закрив на це очі, але ми пишемо сайти для людей яким потрібний хороший UX, моментальне реагування на введені дані та підказки.

Я все ще не бачу проблеми провалідувати це на сервері. Тим паче по секуріті, фронт валідація нічого не вартує, все одно потрібно дані всі перевіряти на сервері повторно.

Я це зробив, аккаунт «Testing»

Добре, я протестую. Але треба розуміти, що кількість рядків в проєкті, а саме 450 майже на все — суттєво не зміниться після виправлення багу. Тобто ми зараз більше займаємося QA тестуванням, а не парадигмою правильної зрозумілої архітектури.
UTube майже весь колись був написаний за добу з купою функціоналу
dou.ua/...​rums/topic/44975/#2694913

450 рядків в сучасному Реакт в вашому проєкті, мабуть тільки код одного банера більше займає. Звідси і читаємость коду, гнучкість коду, кількість багів в коді, щоб це не означало.

Там скоріш всього параметр проганяється через escape, тобто екранує спец символи.
Це не спрацює, або в фейсбуці дійсно сидять трейні.

Я це з нашого робочого проекту (myminifactory.com) взяв, мільйони користувачів

От з вашого робочого проєкту. Перша ж сторінка в анонімній вкладці. Відкрив раз, відкрив два, візуально вони однакові. (чи майже однакові?) То чому цей кейс, коли сторінка відкривається перший раз не кешувати?

мільйони користувачів, повідомлень між ними

З тих мільйонів 10% активні, 90% заходять може раз в тиждень, чи раз в місяць. То чому сторінки для 10% самих активних не кешувати? Далі повідомлення. Чому не кешувати повідомлення користувачів? Навіщо то все кожен раз перераховувати.
Тим паче, в связці фронт-бек база автоматично вміє відслідковувати що змінилося в реактивному стилі, це не коштує в розробці — нічого.

лайки не ставить, коментарі не відправляються

Тому що треба зареєструватися та залогінитися.
Гості не можуть лайкати відео. Коли реєструєшся там відкривається купа функціоналу.

немає клієнтської валідації

Тому що вона не потрібна на клієнті. Кейс коли юзер намагається відправити пустий коментар, це скільки таких випадків серед реальних користувачі ? 0,1% ?
Нехай в цьому випадку нагружає сервер валідацією, то не є проблема.

збивається scroll position

Це не важко зробити, ця задача є в беклозі та буде працювати не на рівні коду, а на рівні платформи.

UX жахливий

А цей myminifactory.com який обвішаний банерами та вспливаючими модальними вікнами наче сайт для дорослих з 90х це не жахливий UX ? )

Коли Реакт появився, всі плювалися від того що в один файл знову запихнули CSS, HTML та JS. Я теж плювався. Всі роки і практики до цього розповідали як потрібно все розділяти. Але нічого, все чудово працює зараз.

Запити в БД пишуться і виконуються на сервері. Просто тепер не треба створювати напряму окремо сервіс який робитиме запити. По суті до CSS, HTML, JS додали ще і запити в БД, але так додали що цей код завжди виконується і залишається на сервері.

Це погане рішення, яке згодом знову перепишуть.

Тобто на сервері ми тримаємо мільйони pre-rendered _user_view.html, мільярди умовних _transacton_row.html і ще сотні компонентів які можуть виглядати по різному в залежності від того хто їх переглядає та які параметри передані

Звідки взялись мільйони та мільярди строрінок ? Можна конкретний а не сферичний приклад сайту ? Там точно не можна нічого оптимізувати ? Наприклад на доу буде макс 500 найбільш переглядаємих сторінок в данний момент, які поновлюються в кеші.

можна посилання на проект з таким рендерингом

Так, можна посилання,
dou.ua/forums/topic/44975

Але є один проєкт, який я вважаю доволі «дорослим». Це портал Fractal Platform. На сьогодні він моделює функціональність Jira, Slack, має свій блог. У нього інтегровані засоби для деплою та моніторингу програм Fractal Cloud, а також безліч звітів, портал для навчання та проходження іспитів студентами. Усе це навантажує складну систему прав на 12 розділів. Весь UI перекладено 7 мовами. Загальна доменна модель, за оцінками, перевищує 300-350 реляційних таблиць.
Із якою швидкістю має працювати такий застосунок? На це питання складно відповісти, але сьогодні це близько 100 мс на завантаження будь-якої сторінки. А на розігрітому кеші час падає до 12-15 мс.

Скрін i.imgur.com/uWqzZbx.jpg

Ну і як виглядає «Реакт майбутнього», а точніше його заміна.
В 450 рядків коду виписаний майже весь фронт-бекенд функціонал на сайт схожий на ютуб
(реєстрація канали підписки лайки коментарі завантаження відео)

fraplat.com/jupiter/UTube

І так, там теж є запити до бази данних прямо з коду, майже як зараз хочуть зробити в Реакт
github.com/...​UTube/UTubeApplication.cs

Але є ньюанс, не лише це має бути зроблено. А коли буде зроблено через 10-15 років все що потрібно, то нарешті застосунки будуть мати не 20 тис рядків коду на подібний сайт, а в ті самі 400 рядків коду. Та латенсі буде не 500 мс, а в районі 100-150 мс навіть без кешування сторінок. А з кешуванням 14 мс як на скріні вище.

Команди розділились на фронт і бек, кожен знає свою область відповідальності. Чому ми тепер йдемо на сервер знову

Тому що це політичні лозунги для роздування штату, а не сухий виважений розрахунок.
В багатьох додатках цей поділ штучний. Ще можна зрозуміти, що бекендер ніколи не зможе гарно малювати дизайн, але коли бекенд і фронтенд все що роблять, перепаковують та валідують одній й тіж самі моделі данних до та після рест апішечки, дублюючи логіку — в цьому немає ніякої доцільності, крім ускладнення проєкту.

Невже не легше було вирішити ті проблеми які є в SPA, а по суті їх лише 3 — SEO, дублікація логіки валідації даних на фронтенді і бекенді та time to first meaningful paint?

Їх не можна вирішити.

Не кажучи вже про цілу низку інших проблем, чисто архітектурного характеру коли єдиний вузел в системі перевантажений саме генерацією динамічного HTML та є вузьким місцем в системі.

Але є ньюанс
1. В статті є контр приклад з Moment.js, де серверу необхідно відправити на клієнт 72 кб. При серверному рендерінгу можна самому все порахувати, та відправити кілька байт як готовий результат.
2. Сервер часто генерує однакові сторінки, та має багато можливостей для кешування та обчислення що називається "не відходячи від каси"©. Перекладати однакову одноманітну роботу на тисячу пристроїв, як мінімум не схвалюють екологи, та виробники батарей для мобільних пристроїв.

Трохи занятно спостерігати, як Реакт наче сліпе котеня, намацує правильний шлях.
Може через 10-15 років буде там де Фрактал вже зараз.
1. Фронт рендерінг
2. Сервер рендерінг
==> Ви знаходитись з Реактом тут <==
3. Сервер та клієнт мають майже однакові БД та спілкуються діфами, замість велосипедування рест апі. Результат: Зменшився обєм коду, зменшився трафік, зросла швидкодія в рази.
4. Оскільки сервер та клієнт повністю знайшли спільну мову, тепер працюють магічні технології, коли база данних відслідковує зміни данних від яких залежать рендерені веб сторінки. Це дає змогу випльовувати вже готові рендерені сторінки за мілісекунди, якщо данні на них не змінились або змінились частково в базі.
5. Енжин навчився генерувати готові веб сторінки використовуючи лише модель данних в базі, що скоростило обєм роботи для круд аплікацій в десятки разів.

В підсумку, що реакт девелопери тільки не видумують, щоб захистити своє право писати в 10-100 разів більше коду, який значно гірше підтримується та повільніше працює. Вони вже інтуітивно розуміють, що там де вони зараз сидять, всидіти довго не зможуть. Але нормально подумати та скласти той весь пазл з фронт-бек-та базою разом не можуть.
Заважає інерційність, "а какжє так"© А вот так.

Скажіть, будь ласка, як ви це бачите?

Що саме бачу? Якщо взяти весь стек вашого коду на Джава
1. На рівні процесору там все кешується в лінійках кешу
2. На рівні дискової системи, все кешується на рівні контроллера.
3. На рівні бази данних там все кешується в своїх локальних кешах
4. І ось прийшов ваш рівень, рівень доменного обєкту і ви такий, нє нє нє ... це не по принципам ДДД бо база данних має бути окремо від домена. Рілі? Яке відношення має одне до іншого. Любий рівень в вашому стеку спроєктований так як спроєктований, та не суперечить доменній архітектурі, тому що купа доменних обєктів що інкапсулюють в собі купу бізнес логіки.

Можете, будь ласка, проілюструвати кодом або псевдокодом:

доменний клас Task з методом UpdateStatus
ентіті TaskEntity
перетворення TaskEntity в доменний клас Task
Можу запропонувати взяти свій репозиторій за основу, але ви, здається, на C# пишете.

Ця задача просто не цікава, вона академічна.
Напишіть в тасці Update Tasks Set Status = Done where ParentId = Id, головне щоб для клієнтського коду нічого не змінилось. Тобто якщо визиває Task.Done(); то виконувалась вся необхідна робота з сабтасками за кулісами.