Все началось с того, что я в очередной раз немного поменял...
Лучшее начало статьи - сохраню себе в памятку! очень открывательная строка. Уверен, что с этого начинаются все увлекательные приключения!.. Пардонюсь за оффтопик, тесты еще надкусываю, тут две статьи подряд погрызть.
Смело написать такое в публичное и циничное пространство. Уважаю. Поддержать не смогу. Сколько людей - столько и диагнозов. Тем более ставить их в интернете - это cross join.
Система — это демиург созданной реальности, главный архитектор, если хотите.. Заботливая мать, которая ... подсказывает возможные решения ...
Здесь что-то про безусловную любовь. Я из текста прочел, что ей вы хотите покрыть всё человечество (или избранных). А как же условная отцовская любовь?! И вообще еще Козьма Прутков говорил: "Стремление обнять и обогреть весь мир чревато растяжением и переохлаждением". То есть идея на новых технологиях, но стара как мир.
В первую очередь мы говорим о субъективном. Потому норм, что у нас разное видение. В ваших словах вижу, что я пока поверхностно юзаю голанг. Соглашусь, вероятно, что когда доведу до ума фронт, то буду иметь сложности в бэке. И возражу - мы сравниваем широкое и глубокое. В бэке сложность растет по мере углубления и, подозреваю, нелинейно. Во фронте сложность входа не связана с html+css - тут сложность на уровне ворда. JQuery пролистнул, но сравню с VBA. Но SPA уже далеко не ворд - есть router, который диктует логику, есть fetch+promises+race'сы. Bootstrap помогает - скрывает кучу интересного. Но как я писал выше, на старте сложность фронта сильно выше голанга. Со временем фронт тоже не упрощается. Почему-то народу проще с нуля переписать на новом фреймворке, чем старое поддерживать. Но тут имхо. И замечу, в голанге лопатить старый код сильно приятнее. Хотя бы из-за запрета цикличных импортов.
Денис, не было задачи объять необъятное. Могут быть и полярные варианты: сервер без фронта, сайт без бэка. Здесь ИМХО, что вход во фронт был для меня тяжелее даже с опытом ворда и HTML+CSS-сайтов. За пределами "входа" особого смысла сравнивать нет - проекты и опыт у всех разные.
Видосики в ютубе иногда помогают. Выше в контексте того, что голанг я запустил по тексту, а с реактом мне документации оказалось недостаточно. Сейчас-то пофиг, а вот прихненел несколько лет назад - оказалось неочевидным, что после установки node.js + `npm i create-react-app` нужно отдельно добавить `npm i` и подгрузить еще 400Mb в папку проекта. А чтобы результат увидеть, то еще браузер запустить. Когда в голанге котлеты отделены от мух заранее, а сам код в байтах измеряется, и результат в консоли.
Меня эта тема пару лет назад интересовала. По памяти напишу. Смысл не в том, что кто-то посередине окажется. А в том, чтобы сервер вообще пароля не знал, который может использоваться где-то еще. И какой-то "полезный" сервер может собирать образцы с логином. В общем, серваку сам пароль и головняк вообще не нужны. Потому при регистрации пользователь генерирует openkey, добавляет salt, хеширует. И на сервер уходит логин, openkey и hash. Какой-то алгоритм гарантирует, что пароль из этого восстановить нельзя. При логине клиент запрашивает openkey к логину, добавляет salt, и отправляет вторым запросом логин с хешем. Сервер сравнивает сразу хэш в бд - сам пароль ему пофиг. В контексте коммента выше в клиенте нужно было согласовать длину полей, соль и обработчики.
Я ж не всё перечислил :) В моем исполнении клиент почти зеркально отражает апи бэкэнда, нечасто удается повторно заюзать эндпоинт сервера. Авторизацию также надо продумывать на клиенте - например не передавать пароль в чистом виде, сначала запрашивать openkey, а на сервер передавать уже хэш. С ролями тоже очень весело - хочется натянуть одну страничку на все роли, но говно получается. В итоге подстраиваю апи сервака, чтобы js-клиент был более аккуратным. Усложнить бэкенд проще, чтобы упростить фронт - такое пока имхо. Решабельно всё, но вход в голанг сильно проще для меня был, чем фронт. Я js-проект запускал несколько дней - до видео в ютубе опустился. Хотя первый сайт на HTML+CSS сделал 25 лет назад.
В целом согласен, что у всего есть сложность. Но как фуллстек имею возражения. В бэке несложного монолита я МОГУ обойтись одним голангом и постресом, которые в общем-то обновляются раз в пару месяцев. И мои сложности начинаются, когда я хочу 10000 пользователей вместо сотни. В маленьком монолите сложностей особых нет. Во фронте я стартую сразу с 10ка технологий. По несколько обновлений в неделю только основных зависимостей. TS помогает, но всё плохо. Язык интерпретируемый, в переменной может оказаться всё что угодно - ts-компилятор помогает, но не гарантирует! Два DOM: react + настоящий. Навигация управляет логикой - в SPA хотя бы можно обойтись одной точкой входа. Состояния только в компонентах, хуки это не компоненты, глобальные и локальные переменные тоже не состояния - и управлять с учетом рендера. Форматы MIME и кодировки text/json/XML. Куки и куча хранилищ браузера. Кросс-запросы и origin's стоили мне нескольких дней жизни. CSS можно прикрутить несколькими способами - и еще смотреть в браузере откуда подтянулось! А ТАКЖЕ куча устройств с различными размерами экрана - писать что-то скрытое, но что открывается при определенной ширине экрана... Хаос начинается с 5 страничек с разными урлами - у меня основная боль именно в UI/UX. И это с учетом того, что это мелкий проект, и я могу не тащить легаси.
Много артефактов проекта в импорте: grpc-service-ref вместо sso - Ctrl+F по тексту!
В tests/suite/suite.go косячок: config.MustLoadPath(configPath)вместо config.MustLoad(). И здесь же неизвестный grpcHost, который или "", или напрашивается в конфиг.
Запуск go test ./tests -count=1 -v фейлится из-за пустого конфига. Не понял как аргумент пробросить сквозь go test, прописал путь в дефолт. Также не очевидно (но просто!), что тест нужно запускать параллельно с работающим app.
Неизвестный emptyAppID в функции TestLogin_FailCases. Предполагаю =0.
Если сразу несколько тестов, то паника "flag redefined". Не понял, как красиво сделать.
Спасибо за работу. Пишу пожелания - пока на запуске миграции. 1. Protos закинул в приватный пакет. Утомился разбираться, как забрать из приватного репозитория. Справился, кучу нового узнал. 2. Пакет Sqlite3 требует cgo(enabled+gcc). Потратил еще какую-то кучку времени. Нашел пакет https://gitlab.com/cznic/sqlite. Удалил пару троечек из /cmd/migator/main.go и заработало. Рекомендую внести изменение.
Такая же статистика была и 25 лет назад - 5% проектов во всех отраслях достигают цели и укладываются во время и бюджет. Плюс что-то достигает с нарушениями времени или бюджета. Причем не факт что указанные 5% были эффективными. Тогда было принято ссылаться на CHAOS Reports, если память не подводит.
В зависимости от интенсивности расходов. Сейчас просто за неделю посмотреть историю по карте. А раньше с наличкой приходилось сильно чаще открывать записи. Знаю, что кто-то просто на бумажке в кармане записывал кому и сколько заплатил, чтобы к вечеру не забыть. Полезный багаж - выучить бухучет (в википедии можно много узнать). К началу своего учета я уже вел управленческий учет на малом предприятии, потому "двойная запись" и "баланс" для меня были открытой книгой.
Уже около 20 лет веду личный финучет. Началось с бизнес-тренинга и поехало. Посмотрел картинки и есть личное мнение (вкусовщина, конечно): 1. Учет вести - это важно! Речь больше не про экономию, а про дисциплину и планирование вперед. 2. Экселя для личного учета вполне достаточно. Обычно достаточно одного рабочего листа простых формул и ручной контроль/перенос остатков. И удобно менять табличку со временем - не тащить древнюю историю в новое время. Плюс таблички на каких-то должников. 3. Далее техническое ИМХО по структуре. Удобнее "одна строка = один день" с группировкой однородных расходов внутри ячейки. А что именно внутри - в комментарии по Shift+F2. Потому что через несколько дней пофигистично наименование "гирлянда, елка", важно "отдых". И табличка за месяц реально умещается на экране 22", можно даже monospace-шрифт в ширину поставить. 4. К предыдущему пункту - почти все крупные расходы являются разовыми или очень редкими. Потому таблица соответствует периоду и должна отвечать на вопрос "в среднем за месяц". Не вижу удобства в том, чтобы повторять записи транзакций в базе данных. В таблицу вносить уже переработанные данные - оборотно-сальдовая ведомость в основе предлагаемой структуры. Щас картинку вставлю. 5. Графики/проценты - ни разу не пригодились! Главное - кому показывать такую презенташку? Для красивой статьи есть резон - не более. Табличка с расходами только для себя любимого, а себе пофиг на сколько процентов увеличился "отдых". Плюс меняется доход, инфляция в стране - два года нельзя сравнивать в процентах. 6. Очень важно. Все деньги в любом случае будут потрачены. Потому надо радоваться, когда в абсолютном выражении числа растут (это не про цены на яйца в пятерочке, канеш!). Потому в какой-то момент переименовал файл с "Расходы 20хх год" на "Блага 20xx год". Потому что нужно менять цель "учитывать расходы" на "увеличивать потребляемые блага" - менять отношение к числам! Как-то так, а сама тема холиварная и бесконечная. Учитывать можно и другое. Например, я как-то год собирал статистику по алкоголю, посчитал за год, что сильно меньше любой статистики и успокоился.
По теме вопроса "Зачем" есть важный психологический прием. Это типа про картинку выше "нахуа", но уже без юмора. Суть - последовательно задавать самому себе вопрос "Зачем" перед каким-то волнительным действием. И так несколько итераций. И где-то к 5-6 псевдопричины-отмазки кончаются, и остается раздетая правда типа "с новой игрушкой жизнь будет ярче". Здесь в статье про как бы рациональное бизнес-поведение. Но я сам убежден, что после какой итерации "Зачем" всё сведется к чему-то иррациональному. Но это уже мое наблюдение как люди принимают решение. И да, лучше если задавать "Зачем" в диалоге - самому себе можно объяснить что угодно.
"Что же касается дискуссий, то единственная возможность победить – не участвовать совсем" - как бы логическая ошибка. Неучастие не равно победе. Можно, конечно, добавить, что такая цель и ставилась. Но в реале все по разным углам разведены. В целом, согласен. Добавлю, что проблема в том, что подразумевается "рациональный" спор, где цель - установление истины. Если расширить в нерациональное, где информация и истина вторичны, то и конфликта не наблюдаю. То есть в общении бывают не только ищущие правду, но и мошенники, и манипуляторы, и абьюзеры, и фанатики и др. И если с какими-то спорить опасно для себя, то с какими-то то не стоит спорить, потому что их мировоззрение развалится, а новое они не потянут.
Не спец конкретно в этой теме, но вижу одной из причин снижение горизонта планирования. Сейчас далеко вперед особо не планируют - там что-то с полки "фантастика". А управление знаниями, имхо, долгоиграющая тема.
Лучшее начало статьи - сохраню себе в памятку! очень открывательная строка. Уверен, что с этого начинаются все увлекательные приключения!.. Пардонюсь за оффтопик, тесты еще надкусываю, тут две статьи подряд погрызть.
Смело написать такое в публичное и циничное пространство. Уважаю. Поддержать не смогу. Сколько людей - столько и диагнозов. Тем более ставить их в интернете - это cross join.
Здесь что-то про безусловную любовь. Я из текста прочел, что ей вы хотите покрыть всё человечество (или избранных). А как же условная отцовская любовь?! И вообще еще Козьма Прутков говорил: "Стремление обнять и обогреть весь мир чревато растяжением и переохлаждением". То есть идея на новых технологиях, но стара как мир.
Приветствую. Ошибка в "полный код" - нет доступа в https://goplay.tools/snippet/UfszC3iDvZW
В первую очередь мы говорим о субъективном. Потому норм, что у нас разное видение. В ваших словах вижу, что я пока поверхностно юзаю голанг. Соглашусь, вероятно, что когда доведу до ума фронт, то буду иметь сложности в бэке. И возражу - мы сравниваем широкое и глубокое. В бэке сложность растет по мере углубления и, подозреваю, нелинейно. Во фронте сложность входа не связана с html+css - тут сложность на уровне ворда. JQuery пролистнул, но сравню с VBA. Но SPA уже далеко не ворд - есть router, который диктует логику, есть fetch+promises+race'сы. Bootstrap помогает - скрывает кучу интересного. Но как я писал выше, на старте сложность фронта сильно выше голанга.
Со временем фронт тоже не упрощается. Почему-то народу проще с нуля переписать на новом фреймворке, чем старое поддерживать. Но тут имхо. И замечу, в голанге лопатить старый код сильно приятнее. Хотя бы из-за запрета цикличных импортов.
Денис, не было задачи объять необъятное. Могут быть и полярные варианты: сервер без фронта, сайт без бэка. Здесь ИМХО, что вход во фронт был для меня тяжелее даже с опытом ворда и HTML+CSS-сайтов. За пределами "входа" особого смысла сравнивать нет - проекты и опыт у всех разные.
всплакнулось даже... жизнь-боль!
Видосики в ютубе иногда помогают. Выше в контексте того, что голанг я запустил по тексту, а с реактом мне документации оказалось недостаточно. Сейчас-то пофиг, а вот прихненел несколько лет назад - оказалось неочевидным, что после установки node.js + `npm i create-react-app` нужно отдельно добавить `npm i` и подгрузить еще 400Mb в папку проекта. А чтобы результат увидеть, то еще браузер запустить. Когда в голанге котлеты отделены от мух заранее, а сам код в байтах измеряется, и результат в консоли.
про НЕпередачу пароля - серверу не нужен пароль для аутентификации. У меня в частности реализовано на jwt-токене.
Меня эта тема пару лет назад интересовала. По памяти напишу. Смысл не в том, что кто-то посередине окажется. А в том, чтобы сервер вообще пароля не знал, который может использоваться где-то еще. И какой-то "полезный" сервер может собирать образцы с логином. В общем, серваку сам пароль и головняк вообще не нужны.
Потому при регистрации пользователь генерирует openkey, добавляет salt, хеширует. И на сервер уходит логин, openkey и hash. Какой-то алгоритм гарантирует, что пароль из этого восстановить нельзя. При логине клиент запрашивает openkey к логину, добавляет salt, и отправляет вторым запросом логин с хешем. Сервер сравнивает сразу хэш в бд - сам пароль ему пофиг.
В контексте коммента выше в клиенте нужно было согласовать длину полей, соль и обработчики.
Я ж не всё перечислил :) В моем исполнении клиент почти зеркально отражает апи бэкэнда, нечасто удается повторно заюзать эндпоинт сервера. Авторизацию также надо продумывать на клиенте - например не передавать пароль в чистом виде, сначала запрашивать openkey, а на сервер передавать уже хэш. С ролями тоже очень весело - хочется натянуть одну страничку на все роли, но говно получается.
В итоге подстраиваю апи сервака, чтобы js-клиент был более аккуратным. Усложнить бэкенд проще, чтобы упростить фронт - такое пока имхо.
Решабельно всё, но вход в голанг сильно проще для меня был, чем фронт. Я js-проект запускал несколько дней - до видео в ютубе опустился. Хотя первый сайт на HTML+CSS сделал 25 лет назад.
В целом согласен, что у всего есть сложность. Но как фуллстек имею возражения. В бэке несложного монолита я МОГУ обойтись одним голангом и постресом, которые в общем-то обновляются раз в пару месяцев. И мои сложности начинаются, когда я хочу 10000 пользователей вместо сотни. В маленьком монолите сложностей особых нет.
Во фронте я стартую сразу с 10ка технологий. По несколько обновлений в неделю только основных зависимостей. TS помогает, но всё плохо. Язык интерпретируемый, в переменной может оказаться всё что угодно - ts-компилятор помогает, но не гарантирует! Два DOM: react + настоящий. Навигация управляет логикой - в SPA хотя бы можно обойтись одной точкой входа. Состояния только в компонентах, хуки это не компоненты, глобальные и локальные переменные тоже не состояния - и управлять с учетом рендера. Форматы MIME и кодировки text/json/XML. Куки и куча хранилищ браузера. Кросс-запросы и origin's стоили мне нескольких дней жизни. CSS можно прикрутить несколькими способами - и еще смотреть в браузере откуда подтянулось! А ТАКЖЕ куча устройств с различными размерами экрана - писать что-то скрытое, но что открывается при определенной ширине экрана...
Хаос начинается с 5 страничек с разными урлами - у меня основная боль именно в UI/UX. И это с учетом того, что это мелкий проект, и я могу не тащить легаси.
Добрался до интеграции с внешним сервисом
Много артефактов проекта в импорте:
grpc-service-refвместоsso- Ctrl+F по тексту!В tests/suite/suite.go косячок:
config.MustLoadPath(configPath)вместоconfig.MustLoad(). И здесь же неизвестныйgrpcHost, который или "", или напрашивается в конфиг.Запуск
go test ./tests -count=1 -vфейлится из-за пустого конфига. Не понял как аргумент пробросить сквозьgo test, прописал путь в дефолт. Также не очевидно (но просто!), что тест нужно запускать параллельно с работающим app.Неизвестный
emptyAppIDв функции TestLogin_FailCases. Предполагаю =0.Если сразу несколько тестов, то паника "flag redefined". Не понял, как красиво сделать.
Спасибо за работу. Пишу пожелания - пока на запуске миграции.
1. Protos закинул в приватный пакет. Утомился разбираться, как забрать из приватного репозитория. Справился, кучу нового узнал.
2. Пакет Sqlite3 требует cgo(enabled+gcc). Потратил еще какую-то кучку времени. Нашел пакет https://gitlab.com/cznic/sqlite. Удалил пару троечек из /cmd/migator/main.go и заработало. Рекомендую внести изменение.
Такая же статистика была и 25 лет назад - 5% проектов во всех отраслях достигают цели и укладываются во время и бюджет. Плюс что-то достигает с нарушениями времени или бюджета. Причем не факт что указанные 5% были эффективными.
Тогда было принято ссылаться на CHAOS Reports, если память не подводит.
В зависимости от интенсивности расходов. Сейчас просто за неделю посмотреть историю по карте. А раньше с наличкой приходилось сильно чаще открывать записи. Знаю, что кто-то просто на бумажке в кармане записывал кому и сколько заплатил, чтобы к вечеру не забыть.
Полезный багаж - выучить бухучет (в википедии можно много узнать). К началу своего учета я уже вел управленческий учет на малом предприятии, потому "двойная запись" и "баланс" для меня были открытой книгой.
Уже около 20 лет веду личный финучет. Началось с бизнес-тренинга и поехало. Посмотрел картинки и есть личное мнение (вкусовщина, конечно):
1. Учет вести - это важно! Речь больше не про экономию, а про дисциплину и планирование вперед.
2. Экселя для личного учета вполне достаточно. Обычно достаточно одного рабочего листа простых формул и ручной контроль/перенос остатков. И удобно менять табличку со временем - не тащить древнюю историю в новое время. Плюс таблички на каких-то должников.
3. Далее техническое ИМХО по структуре. Удобнее "одна строка = один день" с группировкой однородных расходов внутри ячейки. А что именно внутри - в комментарии по Shift+F2. Потому что через несколько дней пофигистично наименование "гирлянда, елка", важно "отдых". И табличка за месяц реально умещается на экране 22", можно даже monospace-шрифт в ширину поставить.
4. К предыдущему пункту - почти все крупные расходы являются разовыми или очень редкими. Потому таблица соответствует периоду и должна отвечать на вопрос "в среднем за месяц". Не вижу удобства в том, чтобы повторять записи транзакций в базе данных. В таблицу вносить уже переработанные данные - оборотно-сальдовая ведомость в основе предлагаемой структуры. Щас картинку вставлю.
5. Графики/проценты - ни разу не пригодились! Главное - кому показывать такую презенташку? Для красивой статьи есть резон - не более. Табличка с расходами только для себя любимого, а себе пофиг на сколько процентов увеличился "отдых". Плюс меняется доход, инфляция в стране - два года нельзя сравнивать в процентах.
6. Очень важно. Все деньги в любом случае будут потрачены. Потому надо радоваться, когда в абсолютном выражении числа растут (это не про цены на яйца в пятерочке, канеш!). Потому в какой-то момент переименовал файл с "Расходы 20хх год" на "Блага 20xx год". Потому что нужно менять цель "учитывать расходы" на "увеличивать потребляемые блага" - менять отношение к числам!
Как-то так, а сама тема холиварная и бесконечная. Учитывать можно и другое. Например, я как-то год собирал статистику по алкоголю, посчитал за год, что сильно меньше любой статистики и успокоился.
По теме вопроса "Зачем" есть важный психологический прием. Это типа про картинку выше "нахуа", но уже без юмора. Суть - последовательно задавать самому себе вопрос "Зачем" перед каким-то волнительным действием. И так несколько итераций. И где-то к 5-6 псевдопричины-отмазки кончаются, и остается раздетая правда типа "с новой игрушкой жизнь будет ярче".
Здесь в статье про как бы рациональное бизнес-поведение. Но я сам убежден, что после какой итерации "Зачем" всё сведется к чему-то иррациональному. Но это уже мое наблюдение как люди принимают решение.
И да, лучше если задавать "Зачем" в диалоге - самому себе можно объяснить что угодно.
Имхо, вы поторопились с комментом. Или я не понял вопроса. Или вообще где мы расходимся в позиции?
"Что же касается дискуссий, то единственная возможность победить – не участвовать совсем" - как бы логическая ошибка. Неучастие не равно победе. Можно, конечно, добавить, что такая цель и ставилась. Но в реале все по разным углам разведены.
В целом, согласен. Добавлю, что проблема в том, что подразумевается "рациональный" спор, где цель - установление истины. Если расширить в нерациональное, где информация и истина вторичны, то и конфликта не наблюдаю. То есть в общении бывают не только ищущие правду, но и мошенники, и манипуляторы, и абьюзеры, и фанатики и др. И если с какими-то спорить опасно для себя, то с какими-то то не стоит спорить, потому что их мировоззрение развалится, а новое они не потянут.
Не спец конкретно в этой теме, но вижу одной из причин снижение горизонта планирования. Сейчас далеко вперед особо не планируют - там что-то с полки "фантастика". А управление знаниями, имхо, долгоиграющая тема.