Чому я створив TechEditor. Історія розробника

Мене звати Віталій Артьомов. Я — засновник Dystlab та головний архітектор TechEditor. Але я не програміст у класичному розумінні. Я інженер, який понад 20 років поспіль стикався з тими ж проблемами, що й ви — рутиною, помилками в розрахунках, постійним перемиканням між різними програмами. І в якийсь момент я вирішив створити інструмент, який був так потрібен мені та моїй команді.

Ця стаття — не просто опис TechEditor. Це моя історія та відповідь на головні питання: яка мета цієї програми і чому вона з'явилася на світ.

Як усе почалося

Розробка TechEditor, цього гібридного текстово-математичного редактору, стартувала наприкінці 2018. Але ідея зародилася значно раніше — просто тривалий час я не знав, як до неї підступитися.

Мій професійний шлях стартував восени 2004. Завершуючи університет, я вже знав, що не піду працювати на будівництво чи у проєктну організацію, а навчатимусь в аспірантурі. То ж наступні 10 років працював на кафедрі — досліджував механіку будівельних конструкцій (мостів), писав дисертацію, виступав на наукових конференціях, вчив студентів. І, звісно, вчився сам.

Я працював в невеликій команді ентузіастів та самоучок, що досліджувала динаміку мостів та їхню взаємодію з поїздами. За 10 років було “перелопачено” величезний обсяг наукової та технічної інформації. В хід йшов широкий набір програмних інструментів: CAD, CAE, математичні пакети, електронні таблиці, мови програмування. Ну і офісні програми, зрозуміло.

Кафедра мостів Дніпропетровського національного університету залізничного транспорту імені академіка В. Лазаряна (зараз УДУНТ), 2013

Програми не рятують від ручної праці

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

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

З офісними пакетами також не усе “гладко”. Наприклад, мені довелося відмовитися від автоматичної нумерації розділів та формул в дисертації і переробити все вручну, адже сторонній плагін, на який я сподівався, на певному етапі дав збій і порушив в Word усю існуючу структуру. Це стало мені уроком, що деякі технології не допомагають, а навпаки — шкодять.

Що більше наукової роботи я робив, то більше замислювався над необхідністю якогось універсального середовища, яке б інтегрувало в собі принаймні текст та елементарні розрахунки.

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

Інженерна практика

У 2014 році я започаткував власну справу і став активно практикувати. Брав участь у різноманітних інженерних проєктах в Україні, Європі, Канаді. Навчав, консультував, менеджерив.

Траплялися проєкти житлових будинків, торгівельних центрів, підпірних стінок, пішохідних та автодорожніх мостів. Нове будівництво та реконструкція. І як не дивно, майже кожна задача потребувала ручних розрахунків. Так-так, не CAE (точніше — НЕ ТІЛЬКИ CAE), а саме класичного, ручного підходу — традиційних формул опору матеріалів, теоретичної та будівельної механіки. Та найбільше “ручної праці” потребувала реалізація емпіричних залежностей, вказаних у нормах проєктування. Плюс оформлення звіту.

Ці вимоги стали особливо помітними під час роботи моєї компанії на канадському будівельному ринку, де ми реалізували більше 100 проєктів.

Спостерігаючи за роботою власного проєктного відділу та консультуючи сторонні інженерні бізнеси, я помітив чітку різницю у підходах до роботи між фахівцями різного рівня. Більш досвідчені фахівці, як правило, доволі універсальні: застосовують спеціалізований софт та легко перемикаються на Excel або інші інструменти. Менш досвідчені інженери — навпаки: майже завжди покладаються на CAE і намагаються “не лізти” в ручний аналіз.

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

Як виявилося, не завжди. Ставка на кваліфікацію окремого інженера, як і ставка на потужність певної програми — підводний камінь, який може створити (і створює!) серйозні ризики для інженерної компанії.

Максимум автоматизації — мінімум помилок

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

Та питання не суто в електронних таблицях.

Провалля в процесах

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

Наприклад, ви:

• правильно порахували в CAE, але помилилися в табличних розрахунках;
• правильно прописали алгоритм в таблицях, але помилилися під час переносу даних з CAE;
• правильно порахували в CAE та коректно прописали формули в таблиці, але помилилися в одиницях вимірювання;
• …

Цей список можна продовжувати, та загальний посил, гадаю, зрозумілий: перериваючи ланцюжок автоматизації, інженер сам того не розуміючи, створює “портал” для різного роду помилок. Частина з них не є критичною, інша — може завдати неабиякої шкоди.

Проблема ховається в тіні

Чому ця проблема не завжди помітна? Бо інженерні розрахунки — вузькоспеціалізована сфера.

У порівнянні з загальним об’ємом проєктних робіт (розробка BIM-моделей, підготовка креслень, деталювання та ін.) це відносно невеликий “шмат” роботи. Невеликий, тому часто не сприймається менеджментом компанії як щось серйозне. “Звіт на 10 сторінок? 20 формул? Ви серйозно? Рахуй на калькуляторі, кидай в ворд і давай готуй креслення, клієнт вже чекає…” — на жаль, такі меседжі не рідкість в багатьох інженерних компаніях.

Так, інженерів, які відповідають за розрахунки і підготовку звітів — мало. Зазвичай, цю роботу в компанії виконують окремі “бойові одиниці”. Їх рідко хто перевіряє. Ну, бо просто нема кому. Цей мікросвіт цілком і повністю може бути зоною відповідальності однієї людини, яка працює за принципом “я так звик”. І не дуже охоча до змін.

Таких висновків ми дійшли 2018 року, який став останнім роком моїх пошуків диво-інструменту для закриття цих та інших потреб. Звісно, пошук вкотре провалився, то ж я вирішив діяти. Це був старт розробки TechEditor.

"Офіс для інженера": рішення все-в-одному

Ще до появи TechEditor в публічному інформаційному просторі, я висунув до нього доволі жорсткі вимоги:

• зручний та максимально зрозумілий текстовий редактор (ми всі дуже звикли до Word);
• висока якість та зручність набору формул (в ідеалі, формули мають виглядати як в книжці);
• вбудовані автоматичні розрахунки (за будь-якими аналітичними формулами, без прив’язки до конкретної галузі);
• підтримка одиниць вимірювання;
• підтримка мов програмування;
• можливість побудови алгоритмічних схем, графів, діаграм;
• та ін.

Звісно, спочатку TechEditor не містив більшості з перелічених функцій — вони додавалися поступово. Перші версії взагалі використовувалися лише для внутрішніх задач моєї компанії, але згодом ми представили цей програмний продукт широкому загалу.

Текстовий процесор TechEditor

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

Формули на LaTeX

Пам’ятаючи про проблеми з формулами в Word та інших офісних пакетах, ми в Dystlab шукали більш надійне рішення. Та воно вже існувало в технологічній сфері ще до появи персональних комп’ютерів на пострадянському просторі: LaTeX.

Пригадую, я спочатку ставився до Латеху з недовірою: чи захоче користувач занурюватися в цю скриптову мову, щоб набрати кілька формул? Та я помилявся. Ми провели серію тестів, які наочно показали, що LaTeX опановується дуже швидко: навіть непідготовлені (нетехнічні) фахівці генерують формули в потрібній нотації за лічені хвилини.

Формули, створені на LaTeX, не змінюють свого положення чи форматування, тобто “не злітають”. Це в буквальному сенсі “залізобетонні” формули.

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

Розрахунки в тілі документа: Excel vs. Mathcad

Як багаторічний користувач Excel та Mathcad, я безмежно поважаю ці інструменти. Вони дійсно служать інженерам “вірою та правдою” вже не один десяток років. Але є нюанси.

В електронних таблицях особисто мені не вистачає "широти розмаху". Коли працюєш з великими обсягами тексту, комірки стають неабияким обмеженням. Та все ж головною перепоною для командної (а часто й індивідуальної) роботи є їхня адресо-орієнтованість — за формулою "C3/C4+C5*100/C6" важко побачити вираз для обчислення напруження в балці "N/A+M/W":

А ми хочемо, щоб було так:

N=10 kN
A=16 cm^2
M=25 kN m
W=300 cm^3
σ=N/A+M/W

Такий вигляд забезпечує інший інструмент — Mathcad.

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

Та Mathcad все одно має обмеження, пов’язане з форматом даних.

Якщо ми вводимо у розрахунок якийсь параметр (x=1), він завжди з’являється на екрані явно. І показати замість нього щось інше (можливо, більш доречне) — не можна. Це обмежує користувача: наприклад, у наведеному вище прикладі замість “σ” можна було б записати щось на кшталт “total_stress” (як це робиться в програмуванні). Але перетворювати технічний звіт на програмний код з довгими назвами — не прийнято, тому користувачі Mathcad та інших продуктів традиційно позначають змінні та функції однією або кількома літерами.

Принцип розділення інформації

Отже, це проблема, коли програма змушує вас підлаштовувати звіт під свою логіку, а не навпаки. Ви отримуєте технічно правильний, але "неживий", важкий для сприйняття документ. Який до того ж часто не відповідає корпоративному стилю або суперечить стандартам оформлення документації (наприклад, ДСТУ). Або й те, й інше.

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

Ось як може виглядати структура обчислень в TechEditor:

AXIAL_FORCE=10 kN
BENDING_MOMENT=25 kN m
SECTION_AREA=16 cm^2
SECTION_MODULUS=300 cm^3
σ = AXIAL_FORCE/SECTION_AREA + BENDING_MOMENT/SECTION_MODULUS

Дуже схоже на програмний код, чи не так? Але подивіться, що відбувається на екрані:

Для скептиків цього підходу завжди залишається варіант працювати з короткими іменами. Зауважу лише, що TechEditor використовує Юнікод, а отже грецькі, кириличні та інші символи в назвах змінних або одиницях вимірювання (навіть в комбінаціях з різних абеток) — цілком допустимі:

Ще раз підкреслю — в переважній більшості математичних пакетів ми не можемо "втрутитися" в формат представлення даних. TechEditor вирішує цю проблему шляхом розділення вхідних (input) та вихідних (output) виразів. У вхідних блоках позначаються змінні та функції, а вихідні — це те, що ми бачимо на екрані.

Тому в TechEditor ми можемо:

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

Такий підхід дозволяє добитися канонічного, буквально “книжкового” формату звіту.

Довільне представлення даних

Я активно використовую механізм розділення input / output для того, щоб параметри у звіті виглядали максимально “природно” — так, як їх звикли і очікують побачити більшість інженерів та науковців.

Наприклад, в нашому документі можуть фігурувати коефіцієнти, які в літературі зазвичай позначаються літерою “γ”. Коефіцієнти — різні, а позначення — однакове.

Щоб ці коефіцієнти відрізнялися у розрахунках, в секції “input” нам достатньо позначити їх різними іменами:

γ1=1.1
γ2=1.2
γ3=1.3

Але читач звіту не очікує зустріти в звіті такі коефіцієнти — він звик до простого “γ”. Наявність індексів та інших символів створить для нього додаткове навантаження і змусить витратити час, щоб зрозуміти логіку розробника. Ми не маємо вводити в оману читача тільки тому, що наш софт інакше не може!

В цьому й відмінність TechEditor від інших програм. Вирази “γ1=1.1”, “γ2=1.2”, “γ3=1.3” ми записуємо в секціях “input”, а секція “output” в усіх трьох випадках містить звичний символ “γ”. Візуально це виглядає так, ніби один і той самий коефіцієнт “γ” виринає в різних місцях звіту з потрібним значенням.

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

Програмування, алгоритмічні схеми та інші “фішки” ТехЕдітора

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

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

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

Простий приклад: додаючи трекбар до свого документу в Mathcad, ми можемо швидко змінювати значення параметру, миттєво оновлюючи весь документ. Дуже зручно! Та цей елемент не є “природним” для матеріалів, які будуть роздруковані чи експортовані в PDF. Те саме стосується і скріншотів, які інженери масово додають до своїх звітів без жодних пояснень та коментарів, створюючи в текстових документах справжнє “графічне пекло”.

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

В TechEditor закладено концепцію “у звіті — нічого зайвого”. Саме тому об’єкти автоматизації, як-от слайдер, селектор чи чекбокс виглядають у звіті як звичайні змінні. Щоб активувати, наприклад, слайдер, користувач двічі клацає по параметру — слайдер з’являється на екрані в окремому вікні. Далі користувач може керувати значенням, рухаючи слайдер курсором миші чи стрілками клавіатури. Завершивши такий зручний “тюнінг”, користувач зачиняє вікно і слайдер зникає, а змінна запам’ятовує поточне значення і лишається у звіті на своєму місці.

Концепція “у звіті — нічого зайвого” працює!

Майбутнє TechEditor: штучний інтелект і що з цим робити

Не встигли ми добряче осмислити та систематизувати наші технологічні здобутки, як отримали нове потрясіння. Штучний інтелект “впав, як сніг на голову”.

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

Як розробник ПЗ, я розумію невідворотність прогресу і неймовірно високий потенціал нейромереж. Тому останні версії TechEditor вже містять інтеграцію з найвідомішими мовними моделями — ChatGPT, Gemini, Grok, Claude та ін. Але ми тримаємо фокус не стільки на автоматичну генерацію контенту (це й так вміють чати), скільки на верифікацію алгоритмів, формул, одиниць вимірювання та інших “чітких” задач, згенерованих штучним інтелектом. Новітнє позиціювання — генеруй з ШІ, перевіряй з TechEditor.

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

Ці та інші питання ми будемо досліджувати далі. Адже історія TechEditor не закінчується — у нас попереду довгий і цікавий шлях. Запрошую вас до цієї подорожі разом!

Якщо моя історія вам відгукнулася або у вас є власні думки з цього приводу — запрошую до обговорення в нашій спільноті в Discord. Буду радий продовжити діалог.