• Порівнюємо код pet-проєктів, що перевіряють наявність світла

    Частково згоден. Але як на мене найкраща документація в brainfuck, взагалі не лишилось не описаних чи не зрозумілих аспектів роботи інтерпретатора =)

    Що насправді важливо розуміти, якщо різниця в х10 разів в ефективності, то вже пайтон відіграє роль brainfuck. Тому що навіть на одному проєкті це економія, умовно 1 вечір з вивченням на Фрактал, проти 5 вечорів на Пайтоні який добре знаєш.
    А на наступному проєкті то вже 1 вечір буде проти 10 вечорів.

  • Порівнюємо код pet-проєктів, що перевіряють наявність світла

    Дякую, мабуть треба буде зробити міграцію на новішу версію.

  • Порівнюємо код pet-проєктів, що перевіряють наявність світла

    Ця стаття більше не про код, а про технології, як писати набагато меньше коду.
    Якщо в ентерпрайз суцільний консерватизм, то для пет проєкту можна вибрати щось більш зручне, що дасть змогу написати весь код за один вечір (100 рядків коду, не тисяча).

  • Порівнюємо код pet-проєктів, що перевіряють наявність світла

    Бо в С нема магії.

    На Сі повно магії. А ось на Brainfuck вже зовсім все просто.
    З однієї сторінки вікі можна повністю вивчити мову, яка складається лише з кількох операторів.
    uk.wikipedia.org/wiki/Brainfuck

    Тому, краще писати на брейнфак, бо краще написати

    навіть в 10 разів більше рядків коду, ніж вчити нову магію.

    =)

    А якщо серйозно, гарний інструмент має економити час, навіть якщо спочатку дещо є просадка на навчанні.

    Підтримав: Denys Poltorak
  • Порівнюємо код pet-проєктів, що перевіряють наявність світла

    Висновок з коду в тому, що там суцільна магія

    "Будь-яка достатньо розвинута технологія, не відрізняєтся від чаклунства"© Артур Кларк, Три закони Кларка

    encrypted-tbn0.gstatic.com/...​hR4ztfa4eiTQmRFA&usqp=CAU

    =)

    simple&stupid.

    Все пізнається в порівнянні
    github.com/p1v2/eSvitlo

    Давайте зробимо експеримент, виберемо будь який не зрозумілий блок коду, та спитаємо GPT, що він робить.

    Виберемо з лямди, та виберемо з Fractal.
    У Пайтона фора, в інтернеті гігабайти коду для машинного навчання. На Фрактал майже нічого немає, лише дуже прості принципи побудови додатків.

    Згода, вибираємо самий не зрозумілий блок коду вище?

    Підтримав: Denys Poltorak
  • Fractal Platform: програмування, якого більше немає

    Насправді все легко.

    5/ уже реалізовано, просто треба покласти ексельку в потрібне місце, і тригернути приховану АПІ.

    4/ це трохи складніше, так як треба підключати Spring Security. Зараз корзина(і сесія) залежить від токену в куках. Немає токену — немає корзини.

    По-перше, там 5 пунктів було описано, тут лише 4 та 5 пункти.
    По-друге, ви замітили, як Java почала тягнути купу підозрілих базвордів, костилів над костилями. Як код який нібито виконував задачі почав потребувати переписування та купи інтеграцій з третіми системами.

    А на фрактал, пейджинг це джисон:
    fraplat.com/...​ionsPages/Pagination.html

    Секуріті це джисон:
    fraplat.com/...​nsionsPages/Security.html

    Локалізація це джисон:
    fraplat.com/...​nsionsPages/Language.html

    Повнотекстовий пошук це джисон:
    fraplat.com/...​mensionsPages/Filter.html

    І так далі. Тобто нема 100500 не схожих одна на одну технологій, є один простий дизайн де ти через Dimensions конфігуриш понад 50 різноманітних параметрів системи.

    Я таке чув від прихильників функціонального підходу, коли вчив як програмувати на Scala. Вони стверджували, що функціональний підхід якимось чином, чистіший, виразніший, ще купу епітетів. Все неправда. Якщо ми говоримо про практичні задачі, функціональний піхід — гірший, так як він просто когнітивно складніший. А для ООП існують паттерни, які дозволяють одному ООПшнику розуміти іншого. Саме тому ООП це командна штука і в цій парадигмі написано більшість софту.

    Фрактал це не просто функціональний підхід. Я з вами згоден, чистий функціональний підхід цікавий більше для математиків. Цікавий саме ФАП — функціонально-аспектний підхід, саме він простіший та дозволяє цілі сайти писати в 40 рядків коду в одному файлі, а далі нарощувати граючись функціонал просто через аспектні діменшини. Це зосвсім інший рівень побудови систем.

    Підтримав: anonymous
  • Стартап: WE.UA — соціальна веб-платформа

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

  • Fractal Platform: програмування, якого більше немає

    Fractal відповідає всього на два прості питання.
    1. Як написати дуже мало коду. А сам код повинен бути дуже простим, зрозумілим і конфігурованим ?
    2. Як зробити так, щоб коли додаються нові вимоги до функціоналу, цей код не переписувати ?

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

    dzmilcatalog.azurewebsites.net/pdp

    Якщо категорії це серіали, а товари це фільми, то найближча аналогія такого сайту онлайн кінотеатр
    fraplat.com/jupiter/Seasons (пароль ps)

    Ваш сайт написано за

    ± 20 годин роботи

    Сайт на Фрактал написано за 15 хвилин.

    Це ми відповіли на перше питання. Теперь відповідаємо на друге питання.
    Сайт на Фрактал вже має:
    1. Пейджинг фільмів (в вашому випадку повинен бути пейджінг товарів)
    2. Він має повнотекстовий пошук (в вашому випадку пошук товарів за іменем)

    Наступна функціональність може бути (як приклад)
    3. Локалізація на кілька мов
    4. Кілька ролей доступу для користувачів, адміни кінотеатру/магазину
    5. Редагування списку фільмів. В вашому випадку редагування списку товарів.

    Тепер ви кажете що за ±20 годин у вас там зявився код на
    Java/Spring/Azure/JS vanila

    Тож питання, як саме потрібно переписати цей код, щоб покрити вимоги 1,2,3,4,5.
    Чи може цей код взагалі не бути переписаний, або він швидко скотиться до boiler plate.
    Додаток на Фрактал не тільки має всього навсього 40 рядків коду,
    github.com/...​ons/SeasonsApplication.cs
    він написаний з дуже правильною архітектурою, яка покриває купу кейсів по розширенню функціоналу в майбутньому.

    Ці підходи зрівнювати, як зрівнювати «напридумували тут ООП, я тут в скипті на пєрл в одній процедурі все накатав». Це дуже різний дизайн систем. Дизайн Фрактал насправді, ще на дві голови вищий за ООП. Він ще більш абстрактний, та неперевершено поєднує простоту та потужність.

  • Стартап: WE.UA — соціальна веб-платформа

    Шкода, що сайт не працює.
    Тож ніша знову вільна.

  • Стартап: WE.UA — соціальна веб-платформа

    Ось би хто соц мережу для ОСББ створив.
    Ніша взагалі пуста. Чати не зручні, одні переклички. Корисного функціоналу там могло би бути вагон. Від голосувань, новин, відеоспостережень, керування парковкою, збору коштів, перегляду заборгованостей, місцеве бла бла кар, барахолка речей, ох є де розгулятись між сусідами.
    Звісно в тій соц мережі буде з 200 людей всього, але будинки можна обєднувати в мережі, а там і монетизація зявиться.

  • Чому я заснував KavunUA?

    Залежить від ТЗ. Якщо ваше ТЗ підпадає під готові вже існуючі шаблони, та ви знаєте що суттєвого півоту не буде, то будь який з існуючих конструкторів підійде.
    Якщо ви маєте щось не стандартне та хочете:
    1. Бути не обмеженими в вимогах та дизайну. Збирай хоч доу, хоч казіно, хоч фріланц біржу, хоч кінотеатр, хоч сайт сканнер
    2. Імплементувати свої вимоги значно швидше ніж на Джумлах-Вордпресах. Той же FreelanceResponse незважаючи на солідний список функціональності, має всього 430 рядків коду. Чистого, функціонального, конфігурованого, а не boiler plate.
    github.com/...​nceResponseApplication.cs
    3. Ваш код має вже в першій версії швидко працювати, та бути готовим бути протюненим на великі навантаження.
    Тоді вибору особливо немає, треба брати ФП, та економити час та гроші.

  • Чому я заснував KavunUA?

    Як я розумію kavun.org.ua це лише лендінг.
    В мене є дуже простий проєкт\заготовка, який моделює BL фріланц біржі: fraplat.com/...​jupiter/FreelanceResponse
    Три ролі, кастомери, девелопери, адміни. Створення задач,
    два тендерних типу між виконавцями.
    Чат між замовником-виконавцем, рейтинги замовників та виконавців тощо.
    Бізнесс логіка може перероблятися під будь які потреби дуже швидко, не вистачає лише на неї натягнути дизайн. Якщо цікаво, та хочете перейти від лендінг до реально працюючого проєкту в стислі терміни — пишіть learn.fractal [sbk] gmail.com

    Схожі ідеї та проєкти зявляються час від часу,
    dou.ua/forums/topic/43440
    але фаундери чомусь не доходять далі лендінгів.
    Тож в цьому я можу допомогти.

  • Fractal Platform: програмування, якого більше немає

    Так, треба буде якось доробити в майбутньому. Найважче знайти десь дані Місто-Координати, щоб заповнити список вибору регіону.

  • Fractal Platform: програмування, якого більше немає

    Дякую за відгук,

    Для бекендера, який витратить місяць-третій на підівчити фронт — це все непотрібно. WordPress, Salesforce, Hybris, Shopify... Платформа на платформі. І так весь кодінг перетворився на конструктор Lego. Збираєш собі з модулів, що душа бажає.

    Ну ось нещодавно в іншій темі душа забажала клонувати доу. Можна? Сумніваюсь, що можна.
    Скільки б в лего не було кубиків, рано чи пізно випливає купа проблем. Пошук потрібного кубіка, інтеграція потрібного кубіка, вирішення проблем як розширити функціонал вибраного кубіка та впихнути туди щось нестандартне, нарешті ціна купівлі того кубіка ...
    Натомість ФП — універсальна платформа, тож зробити клон доу можна було б, мабуть, за тиждень. На класичних інструментах розробки, де бекендер підучив фронт, ну щонайменьше 2-3 місяці. Я розумію, що світу можливо не потрібен другий доу, тож задача притягнута, але потрібен універсальний інструмент, що не обмежує.

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

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

    fraplat.com/jupiter/Weather
    fraplat.com/jupiter/RawForum

    Але що справді цінне, це те, що ви можете вибрати, на які скріни будете приділяти увагу а на які ні. В прикладі з fraplat.com/jupiter/Weather є html верстка, та стандартний скрін де я можу задати gps координати. Тож погоду дивляться всі та завжди, а ось gps координати, скажімо, будуть міняти рідко (як приклад). Тож ви лишаєте скрін в «чорно-білому» стилі, для змін координатів, а html верстку замовляєте в дизайнера.
    Якщо ви б використовували стандартні засоби розробки й внутрішні, й зовнішні, й скріни які просто щось конфігурують вам потрібно було б дизайнити відразу з нуля та витрачати на це час.

    Нащо змагатися з кимось, у кого є необмежена кількість грошей, і купа головастих задротів літкодерів? Вони всеодно напишуть краще ) Ой... Уже написали, тобто.

    Насправді це міф. Великі корпоративні компанії не гнучкі, мають багато бюрократичних обмежень, та дуже повільно змінюються. Apple при Джобсу, може була чи не єдиним виключенням. Купа продуктів, які дійсно змінювали світ, Oculus, Android, OpenAI виходили з стартапів, та далі або виростали з гаражів в великі компанії, або куплялися великими корпораціями як готові продукти.

    Підтримав: anonymous
  • Fractal Platform: програмування, якого більше немає

    Ну що хлопці, а особливо дівчата :)
    Хочете себе відчути справжніми CRUD девелоперами веб сайтів ?
    1. Заходите сюди fraplat.com/jupiter/JsonToWebApp
    2. Вставляєте в віконце свій Json (можна досить великий)
    3. Нажимаєте на кнопку «Build My Web App !»

    а далі ....
    1. Ви отримуєте справжній CRUD веб апп
    2. Отримуєте вже задизайнену БД, яка може складатися з кількох таблиць та звязків між ними (в залежності від складності джисона)
    3. Отримуєте весь прошарок з DTO та ORM, та обвязку
    4. Отримуєте рендеринг фронта: текст бокси, чек бокси, таблиці, вкладені форми інше
    5. Всі скріни відкриваються та зберігаються за лічені мілісекунди.

    Поздоровляю, тепер ви — майже справжній Fractal Developer веб сайтів
    Magic =)

  • Fractal Platform: програмування, якого більше немає

    Кеш — зовнішній компонент, котрий не викликає бізнес-логіку.

    Цінність кеша, якщо він під рукою, як в процесорі L2 наприклад. Тож він може бути частиною самого процессора, а це вже не stateless, та йиовірність що щось сбоїть бо стан системи особливий.

    Ну от в геймдеві використали.

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

    Підтримав: Denys Poltorak
  • Fractal Platform: програмування, якого більше немає

    Це гарна теорія, але тяжко яка реалізовується на практиці. Реальна програма на кожному степі може вигрібати та обробляти десятки мегабайт данних з бази, які будуть дублюватися в рекорді реплея. Інша проблема, що сервер може бути не stateless, а він майже завжди такий. Щось кешує, десь оптимізує.

    Тож по хорошому треба дампити і бд і адресний простір серверу як процесу і мокати далі всі коли до 3d party систем, включаючи ОС.

    Але, саме ФП з її концепцією CMDD (в статті зверху є розділ), найбільш близький до цього, тож Autoreplay може бути всього лиш ще одним Dimension, який в паралельному вимірі каже нам, що тепер ми у всіх кутках системи читаємо снепшоти в розрізі часу. Це справді реально, можливо навіть десь в пристойні 10к-15к рядків коду, та багато думати =)

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

  • Fractal Platform: програмування, якого більше немає

    RDBMS це Relational Database.
    FP живе на Key/Value, поверх якого абстракції json документів.

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

    Підтримав: Denys Poltorak
  • Fractal Platform: програмування, якого більше немає

    Хм, цікава функціональність.
    Але як на мене тут є кілька обмежень:
    1. Автореплей мішає не тільки багатопоточність, а перш за все зміни в базі данних. Саме тому AutoTesting працює на еталонних базах.
    2. Автореплей який включено на постійній основі, може сповільнювати запити користувачів
    3. Автореплей повинен вміти мокати недетерміновані змінні. Наприклад час, та генеровані гуїди.

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

  • Fractal Platform: програмування, якого більше немає

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

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

    У вас там event replay не можна використати для відтворення багів?

    Є логи. Багато чого можна просто подебажити. Щоб кожен раз не перетестовувати все після змін, є Auto Tests з кілька десятків тестових сценаріїв. Тобто вбудована можливість self testing, або простіше кажучи, перевірити що кожен з тестових проєктів працює як раніше після якоїсь суперечливої зміни. Це дуже сильно допомагає, бо найгірше якщо якась нова зміна ламає щось в якомусь з 25 вже існуючих проєктів, а перетестувати все мануально після кожної зміни фізично важко.

    Підтримав: Denys Poltorak
← Сtrl 123456...9 Ctrl →