Привет, хабровчане!
UPD: ссылка не прикрепилась, и я благополучно ушел на созвон. Вот она, со всем уважением, короткий видос в ютубе и в ВК (там еще обрабатывается)
Давно не писал, потому что для меня Хабр изначально был DIY-тусовкой, в хорошем смысле этого слова, а у меня ничего DIYйного не было.
А сейчас вот появилось -- решил демонстрации ради запилить Notion из рельсов и шпалок.
К постановке вопроса зачем мы вернемся, как это принято тут и у всех айтишников -- в самом конце, а сейчас к конкретике и без воды:
Прям вот с нуля, только с персональной подготовкой (20 лет в деле), до записи видео просто освежил и прозвонил руками тонкие для меня места, чтобы не пороть запись.
Минимальное количество зависимостей, только когда прям надо.
Ruby on Rails из коробки как идет.
Frontendless - никакого JSON и фронтенда*
Realtime - ве живое и шевелится через вебсокеты и прочие турбофреймы
Винда + WSL.
Tailwind и все его замечательные трюки
Hotwire StimulusJS + SortableJS, Stimulus-use, Stimulus dropdown
Интернационализация - ru
Ну и так по мелочи.
Перечень реализованных фичей вот такой:
Регистрация, Авторизация
Воркспейсы
Страницы - иерархия, сортировка вложенности, домашняя страница
Текстовые блоки с файловыми вложениями, обработка изображений
Инициализация таблиц из CSV
Преобразование из Markdown, pandoc
Табличные свойства - настройка свойств мульти выбора, одиночного выбора, отображения валюты
Закрепление view версий таблиц
Фильтр содержимого - сортировка по датам, изменения состава отображения, количества ячеек, значения колонок
Ну и зачем все это, спросите вы?
Дело все в том, что я хотел подсветить болезненные вопросы для сегодняшних предприятий, на которых они попадают в болото зависимости от непонятно чего, и не двигаются туда, куда им нужно двигаться.
Самое интересное что это я уже руками делал внутри определенных компаний, в разной форме в разное время.
Это наилучший способ продемонстрировать новичкам как нужно решать задачи. Программирование тут ровным счетом не причем.
Необходимо получить пробу, работающий в реальных условиях продукт, а только после этого заниматься оптимизацией и прочими деталями. Получи потребление, а потом на замерах принимай нужные меры.
В мире разработки сейчас не нужно ничего "закладывать" на будущее - все скейлится тянется и переписывается когда надо, полон хабр этих историй.
А вот про решение задач мы мало слышим, потому что это не такая интересная тема.
Итак мои утверждения на прожарку, уважаемым вам:
1. Любой софт заменять можно и нужно.
Ну для начала пример готов -- сделать замену notion в вашей компании возможно.
Наблюдаемый результат за 6 часов. А что если поработать пару дней?
Я придерживался всегда одного утвреждения -- вы должны владеть своими данными.
Начиная даже с прав на доменное имя, вы не поверите, но буквально пол года назад один из контрагентов оказался без трех адресов своего "бренда", потому что они принадлежат трем разным "бывшим партнерам".
Это данные, критичные. Не стоит недооценивать предсказуемость тупизны (с) Тони.
2. Всегда достаточно базовых фичей.
Все прекрасно знают рассказы про то, как в MS Word большинство использует до 3% функций.
И эти функции повторяются примерно одинаково в любом Wysiwg редакторе.
Все остальное это уже обвес бизнес продукта для расширения зоны покрытия потребителей.
Но если мы рассматриваем всегда конкретное предприятие и конкретные потребности, выясняется что не просто нужны, а именно употребить в своих бизнес процессах конкретные команды способны лишь пару фукнций в их ограниченном объеме.
На остальное у них просто не будет ни времени ни желания.
Это вообще тема отдельной дискуссии, которая нас приведет прямиком к Системной инженерии, к ТРИЗу и к принципам Форда, Тойоды 5 почему и тд.
Полуить необходимое можно и нужно в минимальном объеме.
Приведенный мной пример это демонстрирует наглядно. Да, вы не сделаете замену Ноушну в виде конкурирующего сервиса, это вообще отдельная песня.
Но взять под контроль инфообмен вашей команды, ваших сотрудников раз и навсегда, с возможностью не зависить от вендора, за примитивно кратчайшее время -- вот вам пример.
3. Стоимость замены.
У меня есть (возможные) идейки насчет этой демки, убрать лишний код, написать то самое тз какое должно было бы быть на этот продукт, и покрыть тестами (именно в таком порядке, дайте ответы в комментариях почему).
Это не значит что вот все готово переезжайте, но это значит что разговоры (которые у меня идут и будут регулярно продолжаться) с технарями, на момент формирования планов в IT отделов как нам быть и куда плыть, не будут содержать таких фраз как "x человеко-лет, даже и не думайте".
Ровно для таких случаев сделана демонстрация. Те, кому нужен результат, чтобы определенные данные начали циркулировать на определенных условиях, и при этом что данные, что само их циркулирование принадлежало компании -- всегда верно дают оценку и команде, которая это блокирует, и таким решениям, которые в конечном итоге не просто оптимизируют что-то там где-то там, а укрепляют компанию на годы вперед.
Свой софт дает опору для решений, которые нельзя было принимать в угоду "сложившимся микросервисным обстоятельствам" и тд и тп.
4. Практическое обучение разработчиков на примере.
Лучший способ снять миллиарды вопросы а как а что а куда.
Пользуйтесь, именно трюк с разработчиками я проводил многократно, скорость ввода в эксплуатацию новых разработчиков (а в свое время приходилось конвертировать из PHP в Ruby, сейчас добавился еще JS/TS и Python, но сути не меняет).
Всегда при спорных вопросах предлагается реализовать аналогичное в такое же время -- пожалуйста.
Даже если ты готовясь длительное время изготовишь, ты попадешься мне на вот такой трюк: а давай ка ты возьмешь любой другой продукт, и продемонстриурешь именно его бутстрап за аналогичное время.
Вот тут и просыпается понимание у новичков и интересующихся, а куда имено тут смотреть. Все верно -- на принятие решений как поступать в конкретный момент времени.
Опыт есть путь ошибок неверных решений. А когда у тебя надежный конь (в данном случае рельса), то тебе будет проще совершать ошибки.
И ты поймешь, что самое главное в прохождении вперед по опыту -- это набор ошибок.
Как их набирать ты будешь выбирать сам, я же просто показывая развлекаюсь.
5. Фронтенд не нужен.
Вся эта пляска с запаковкой смыслов в json, а потом обратно, синхронизация стейта, ГрафКУЭЛЬ о боже мой, короче, можно без этого жить и делать вещи, друзья.
Надеюсь, вам было полезно и интересно, ссылка на видос на ютубе.
Немного про отечественные заменители:
Заблокированный ютуб прожевал, обработал и запушил в течении 2х часов вчера.
Вк на эту минуту еще обрабатывает, загружался всю ночь.
Дзен не пропустил по лимиту файла — до 70GB.
Рутуб не пропустил по лимиту времени — до 5 часов.
Платформу я даже не трогаю, уровень забагованности и падений с перового дня просто не дает пользоваться.
Комментарии (23)
zabanen2
02.09.2024 10:25+4какое-то неуважение к зрителю отдавать в непрерывном 6-часовом видео. и ладно бы здесь были выкладки, но вся эта статья выглядит как промо для ролика.
upd прошу прощения за в целом негативный комментарий. добавляю ответ сюда, т.к. у меня низкая карма. видео показалось интересным, но его формат огорчает. хотя бы добавить главы (таймкоды) в видео
apavlyut Автор
02.09.2024 10:25это и есть промо ролика чтобы посмотреть как делать с нуля такой продукт.
нарушено какое-то правило?
apavlyut Автор
02.09.2024 10:25какое-то неуважение к зрителю отдавать в непрерывном 6-часовом видео
Судя по сегодняшним тенденциям могу вас поддержать, скорее всего виноват Ютуб.
Потому что если бы он не предупредил такую возможность, я бы вас не задел своей рукопашной работой длиной в 6 часов.
Просто думал что это будет кому-то интересно также как и мне.
apavlyut Автор
02.09.2024 10:25upd прошу прощения за в целом негативный комментарий. добавляю ответ сюда, т.к. у меня низкая карма. видео показалось интересным, но его формат огорчает. хотя бы добавить главы (таймкоды) в видео
все норм, я знаю какая реакция должна быть на хабре, ее и наблюдаю.
будет замечательно что сейчас загасят DIY материал (а что-то в нем кроме самоделки нет) на самом базированном DIY ресурсе.
Мое почтение, а вам спасибо.
Большое видео тяжело куда-то залить, обрабатывать и тд.
Для хобби у меня нет таких ресурсов, со времем может быть.
Я просто включил камеру и сел и за 6 часов сделал что хотел.
Ну видимо хабровчане лучше знают, и покажут свою оценку -- мы же ею насладимся.
IIopy4uk
02.09.2024 10:25+1сейчас загасят DIY материал
на самом базированном DIY ресурсе
За дело, если на то пошло - подача материала весьма хромает.
Нет структурированности текста: мысль хаотично прыгает от темы к теме, какие-то внезапные для стороннего читателя отступления.
Заявленная в тексте задача не решена. "Сделал видео как создать Notion" не равно "Создать Notion".
Возможно, кого-то напряжёт самолюбование и нарциссизм автора (лично я над этим похихикал).
apavlyut Автор
02.09.2024 10:25перечитай материал еще разок, я добавил форматирование.
кстати на одной из переписок я сконвертировал сишника в рубиста, думай
Kill_Voice
02.09.2024 10:25+6Пытаться что-то быстро переписать с нуля это максимально глупое, что можно сделать для решения любой задачи. В своём опыте я уже наблюдал несколько таких амбициозных «поделок». Начинается всегда одинаково, сейчас мы сделаем mvp за час, день, неделю(нужное подчеркнуть) в итоге получают quick win и говорят вот нам нужно месяц чтобы доделать вообще всё. Далее проект начинает тонуть в мелочах, команда просит еще месяц, потом еще, незаметно проходит год, и вроде как это уже всё нужно остановить, но денег потратили столько, что никто не хочет брать на себя такое решение. В итоге всё заканчивается каким-то Франкенштейном который непонятно кому и нужен
apavlyut Автор
02.09.2024 10:25а тут секрет то прост - ответы на вопросы зачем переписывать нужно получить до переписывания.
и да, они редко бывают положительными, но бывают.
вы говорите именно о тех переписываниях, про которые я тоже прекрасно рассказывал -- как программисты играют в игрульки за счет работодателей, для прокатывания скилов в свои резюме.
не надо путать переписывание для закрытия потребностей и укрепления бизнеса, и переписвания для прокачки скилов за счет бизнеса и в минус ему
eugenes_tp
02.09.2024 10:25+5Непонятно ровным счётом ничего. Сделал демку Notion? Где она? Сделал видео на эту тему? Где ссылка на него? Какой-то поток сознания ТСа
apavlyut Автор
02.09.2024 10:25Ссылки не закрепились, копипаста, прошу прощения.
Добавил ссылку на видео, пока живой только ютуб, вк уже 12 часов старается, думаю скоро сможет.
namikiri
02.09.2024 10:25+2Видосы на текстовом ресурсе — моветон, ссылки на них ничего не оправдывают. Text or GTFO, как говорится.
ancros
02.09.2024 10:25+1Вся эта пляска с запаковкой смыслов в json а потом обратно, синхронизация стейта, ГрафКУЭЛЬ о боже мой, короче можно без этого жить и делать вещи друзья.
Была бы карма, поставил бы плюс за это.
Осознание, что толстые клиенты практически бесполезны придет постепенно и болезненно.
Это не более, чем хайп и пустая трата ресурсов клиента
tzlom
02.09.2024 10:25ну да, пока у тебя один юзер действительно все равно кто толстый
ancros
02.09.2024 10:25+1Вот так и продали идею толстых клиентов
Сервер все равно должен отвечать данными на сменю любого важного состояния. А состояния типа скрыть показать блок это не толстый клиент
Общение джсонами между фронтом и бэком в рамках разумного это не плохо, но текущая ситуация с разработкой фронтенда на "современных" фреймворках (и библиотеках) это катастрофа
tzlom
02.09.2024 10:25Я придерживаюсь мнения что если отдельная команда не осилила толстые клиенты то и тонкие она бы не осилила, а выбор между ними диктуется приложением, стеком технологий и планами на 3 года
ancros
02.09.2024 10:25Вопрос разве в том, кто что осилил? Речь про эффективность приложенных усилий. Я видел сильные команды, которые делали сложный фронт, с архитектурой, тайпскриптом и тд. Но эти проекты работали не очень хорошо с точки зрения пользователя. Долго грузились, ужасные анимации и тд. И исправить они это не могли, потому что ограничения "библиотеки". Хотя внутри просто рай для глаз программиста
Давайте будем честны, стек определяется теми, кто продает услуги по разработке. А кто сейчас не следует трендам? Чтобы взять на себя ответственность и предложить более совершенное и эффективное решение нужно посмотреть на разработку под другим углом. Например насколько сильно современный стек ограничивает возможности оптимизации, реализацию любой хотелки заказчика (ведь нельзя сказать клиенту, что его идею невозможно реализовать в текущем стеке) и сколько усилий придётся приложить для решения любой бизнес задачи.
Планы на 3 года это очень хорошо, но если сегодня популярен Реакт, а через год появится Херакт, который решит все проблемы разработки интерфейсов (нет), да и дизайн пора обновить... думаете клиенту не продадут написание проекта с нуля на Херакте?
orefkov
02.09.2024 10:25+1У Джоэла Спольски была в своё время статья "Верблюды и песочницы", оттуда тезис "Как известно, 80% пользователей используют только 20% программы. Но не думайте, что реализовав 20% фич, вы получите 80% пользователей. Потому что эти 20% у всех разные". То есть каждому будет не хватать какой-то своей фичи, в итоге продуктом будут мало пользоваться.
apavlyut Автор
02.09.2024 10:25У сапольски на эту тему очень много интересного.
Но это утверждение прямо верное. Главное реализовать быстро для проверки малой кровью, а дальше уже другая история.
Выкинуть самопал который сделан за короткое время намного приятней и проще чем втянуться в разработку у утонуть в ней.
Apv__013
Не отпустит ни как?
apavlyut Автор
поставил тебе лайк, ты видимо из постоянных зрителей моих телепередач.
ну как тебе рубрика оч. умелые ручки?