Жаба гадюку

Щож, маємо гарні новини. Віртуальні машини Fractal Cloud витримали перше навантаження, помилки були але не критичні, та стосувалися в основному закритих аплікацій на Fractal.

Але пост трохи не про це. Ви знали, що 15 років тому на youtube було завантажено перший ролик на youtube, Me at zoo www.youtube.com/watch?v=jNQXAC9IVRw
Так ось, в мене є мрія завантажити такий самий, аля я на Стугні, але вже на власний ютуб.

Ну це був майже жарт, але помятаєте, що я писав про «Твій ідеальний день» в статті.
Тож на годиннику 9:37, чашку кави я вже випив (будемо вважати що 5% справи вже зроблено :D) та наступні 24 години я буду намагатися створити MVP на youtube.

В функціоналу сайту має бути.
Для користувача:
1. Реєстрація користувачів, редагування їх профайлу
2. Створення каналів відео (chanels)
3. Завантаження/Видалення відео на каналі
4. Лайки/коментарі/кількість переглядів під відео
5. Підписки на канали
6. Борд з рекомендованими відео
7. Історія перегляду відео
Для адміністратора
1. Можливість модерувати юзерів
2. Можливість модерувати канали

На все про все в мене є лише 24 години. Тож в ідеалі наступного ранку, до 10й години, я вже маю завантажити перше відео на сайт. Сказати що це мало, це не сказати нічного. На доу багато гарних спеціалістів що використовують самі різні технології. Як би не було FP, мабуть, я резервував би на цю задачу десь тіму з 5 чоловік, та щонайменьше 2-3 місяці роботи лише для MVP і це ще якщо пощастить.
Але буду чесним, я зроблю собі трохи скидку, тож гарний UI буду робити в останню чергу, сайт донор з гарним UI не так просто знайти. Але весь бізнесс функціонал має працювати так як треба.

Тож. Challenge Accepted :)

PS:
Доречі, ми продововжуємо комплектацію тімів для навчання та подальшої розробки проектів, в понеділок усі зареєстровані на почту отримують доступ до навчальних матеріалів.
fraplat.com/jupiter/ToDoIntro (реєстрація в кінці презентації)
Мета Fractal Platform дійсно істотно змініти ландшафт розробки ПО.

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

Fractal прогресивно підходить до рендеру інтерфейсів. Standard UI (що описаний в статті) для нас цінний тим, що він нам дістається безкоштовно. Маючи лише Json, Fractal вміє на основі його побудувати цілу серію форм.
В багатьох випадків цього достатньо, але в більш складних випадках, в нас є такий інструмент як RenderForm.
github.com/...​ations/Chat/RenderForm.cs
Ми можемо рендерити будь-який інтерфейс, будь-який html.
Ось приклад рендеру подібного інтерфейсу до шахової дошки.
Це календар мітингів на платформі.
ibb.co/Cwg3HkX

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

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

Оце насправді питання на мільйон. В розділі Database статті описується саме концепція, коли в вузьких випадках ми можемо створити свій унікальний рушій (Storage) та заінжектити його для зберігання та пошуку інформації. Якщо типові бази данних, накшталт, Mongo чи PostgreSQL не дають нам такої гнучкості, та вносять свій overhead, лише Fractal дає змогу дійсно добре затюнити прошарок зберігання інформації зпустившись на рівень простих та ефективних структур данних створених під задачу.
В статті в розділі Database це питання розкрите більш змістовно.

Нажаль, навколо GPT багато хайпу та клікбейту.
Тут я дав розгорнуту відповіть, на рахунок перспектив AI
dou.ua/...​rums/topic/44975/#2693836

Імхо подібні проекти цікаві більш як інтеллектуальне кунгфу, але до чогось практичного не призведуть.

Чи можете розкрити тему більш детально ?
Я вважаю що в наступні роки, Low Code системи складуть гарну конкуренцію не тільки класичним методам розробки, але й таким підходам як ШІ та GPT.
Недолік GPT, що його навчали програмувати на досить складних технологіях, при яких він допускає досить багато помилок. Але не лише в цьому проблема. Проблема в тому, що навіть якщо GPT вже майже ідеальний розробник, то на виході ви отримаєте щось накшталт такого на запит розробити форум на php:
github.com/phpbb/phpbb
А це мегабайти коду. Тож коли ви захочете внести суттєві зміни в цей код, це не буде швидко.
Натомість на таких LC як Fractal код виглядає значно коротшим та простішим,
але головне його легше підтримувати, модифікувати та читати:
github.com/...​les/Applications/RawForum

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

Мій рушій на сервері вміє видавати трохи більше інформації (наприклад оцінку з tablebase). Хотілося б її прокинути нагору. Тобто щось на кшталт lichess, lidraughts. Використати WebSockets або quic

Звісно, але для цього Вам потрібно буде зробити REST сервіс, який віддає Json з оцінками tablebase. Як тільки ваш рушій зможе віддавати такий Json, Fractal побудує весь інтерфейс навколо Json автоматично. А також дасть змогу кастомізувати інтерфейс при потребі.

Далі, у мене є також консольна програма для гри у футбол на аркуші паперу youtube. Хотілося б написати щось подібне у web.

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

Далі, усі існуючи шахові бази даних орієнтуються на партії. Мені було б цікаво написати базу, яка б орієнтувалася на позиції. Наприклад для кожної позиції ми можемо прочитати коментарі з усіх книжок, щось на кшталт wiki. Щось подібне є на lichess, але мені хочеться своє.

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

Дякую за фідбек !
В кінці короткої Intro презентації є форма, де можна залишити свої контактні данні.
fraplat.com/jupiter/ToDoIntro
Увага, це не landing page. 18 вересня всі хто зареєструвався зможуть отримати права доступу на Fractal Platform та доступ до всіх навчальних матеріалів. Також номінально Ви будете закріплені за командою, що буде мати deployment key для розгортання додатків в інфраструктурі Fractal Cloud.
Мета створення команд — на першому етапі: навчання, злагодження, створення тестових портфоліо проектів. На другому етапі — виконання оплачуваних комерційних замовлень.

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

Але... GetFirstDoc. А чому не GetLastDoc? Ось тобі можлива помилка.

Насправді буде працювати і з GetLastDoc, тому що в колекції всього один документ, який ми редагуємо
github.com/...​/Document/0000000001.json

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

Звичайно є прості приклади, які пишуться просто. Є складніші, які пишуться більш складно.
Але важливо, що все створюється в єдиному стилі, тому при певному досвіді все не виглядає як набір трюків. Наприклад тут моделюється OnlineShop, з категоріямі товарів, з продуктами, з фасетним пошуком. Документи тут збираються з кількох джерел в кілька етапів.
Код складніший, але це все ще лише просто набір функціональних виразів які досить прості для розуміння, зібрані в одному файлі.
github.com/...​s/Applications/OnlineShop

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

Так, тому на FP створено більше 20 різних додатків. Головним критерієм вибору для створення було — протестувати гіпотезу, що це дійсно універсальний інструмент. Тому, якщо ви захочете створити свій додаток, або модифікувати існуючий, дуже ймовірно що знайдеться вже готовий робочий приклад. FP гарний тим, що дійсно нагадує 3D принтер, який мінімально обмежує можливості розробки (за рахунок CMDD). В той час як інші Low Code системи більше нагадують Lego конструктор.

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

Виглядає як срібляна куля, писати код без багів. За 70 років розвитку IT найсвітліші голови розвивали цю тему, але гарного рішення не дуже видно.

Повністью згоден. Тому FP лише наближається до цієї моделі, це складно, але можливо.
Наприклад, типовий код ToDoList виглядає лише як один функціональний вираз.
Тож зробити помилку в ньому досить складно.

github.com/...​s/ToDo/ToDoApplication.cs

При цьому, якщо писати такий же додаток за допомогою інших мов програмування, з залученням ORM, REST, Dto, MVC, JS та інших прийомів програмування, то звісно простір для допущення помилки значно ширший.

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

Так, звичайно є певний артефакт Low Code систем, які для девелопера виглядають як Black Box, особливо коли зтикаєшся з платформою перший раз. Але FP дає перевагу в швидкості розробки застосунків, тому навіть в найгіршому випадку «розробка на FP + консультації» може виявитися набагато коротшим шляхом, ніж «звичайні інструменти розробки + багато дебагу».

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

github.com/...​ons/SeasonsApplication.cs

Пароль ps (лише для друзів з Dou :))
fraplat.com/jupiter/Seasons

Ви можете порівняти складність написання цього проекту на ваших поточних інструментах розробки. Та навіть з застосуванням таких інструментів як Chat GPT.

Дякую !

Дякую за гарне питання !
Відповідь знаходиться одразу у декількох площинах.
Перша площина — як і інші платформи, Fractal Cloud має розгалуджену систему помилок.
Наразі є біля 200 різних типів помилок, кожна з котрих має свій код та тлумачення. Також при виникненні помилки в нас є логи з stack trace, які можна переглядати через веб інтерфейс на платформі.
Друга площина — більшість помилок, за досвідом, мають синтаксичний характер.
Тож в Fractal Platform інтегровано кілька валідаторів, що валідують конфігурацію перед запуском додатку, що допомогає знаходити помилки на ранніх етапах.
Третя площина — і наразі я рахую її головною, це те, що ми пишемо код в функціоно-аспектному стилі (ФАП). Тож в переважній кількості випадків цей код працює з першого разу. Це нагадує те, як ми пишемо запити до бази данних SQL. Зазвичай, на відміну від імперативного коду, нам не потрібно займатись низькорівневим дебагом коду накшталт SELECT * FROM .... Якщо щось не працює, то помилка зазвичай знаходиться десь на поверхні і її легко знайти. Тож Fractal Platform наближається саме до цієї моделі відлагодження коду.
Крім цього, в складних випадках помилок, команди що розробляють додатки можуть замовити консультацію Core тіми на платформі, та отримати вичерпну інформацію про причини помилки.
Також на FP створено спеціальний форум для комьюніті, де можна обговорити причини виникнення помилок та ділитися досвідом.
fraplat.com/jupiter/RawForum

Світ належить божевільним ідеям. Це правда. Але лише тим, що втілилися в життя.

Бо на такому рівні крутяться обмежені проєкти

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

Одне одному не заважає. В великих проектах посередені купа посередників.
І така фріланц біржа може бути лише одним з підрядчиків в ієрархії на нижньому щаблі, для простих ізольованих задач, де не потрібно підписувати NDA

Опен сорц якось працює. Без відбору виконавців і навіть без оплати праці. Як я поняв автора, це щось середнє між опен сорц (де взагалі не платять) та галерами (де платять але відібраним).
Тобто середина, це десь — платять всім, але не топово, та за задовільно виконану роботу. А для замовників, щоб зменшити ризики, одна з стратегій може бути продублювати задачу серед кількох виконавців.

most_common

Это не декларативный стиль.
Важно ведь не только кратко и выразительно реализовать задачу, важно чтобы реализация была достаточно гибкой для новых изменений. Так вот прелесть sql и с# (linq) что он выписывает алгоритм как композицию из простейших функциональных преобразований.
Например, сегодня задача звучит как «собрать 5 наиболее частых сигналов с датчика за период»
А завтра
«Выяснилось что датчики имеют погрешность −2/+2»
В декларативном стиле сделать изменения элементарно. Верчу как хочу.
Как встроить в most_common округление — не понятно, потому что это ситуативный пайтоновский костыль.