Денис, не было задачи объять необъятное. Могут быть и полярные варианты: сервер без фронта, сайт без бэка. Здесь ИМХО, что вход во фронт был для меня тяжелее даже с опытом ворда и 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 псевдопричины-отмазки кончаются, и остается раздетая правда типа "с новой игрушкой жизнь будет ярче". Здесь в статье про как бы рациональное бизнес-поведение. Но я сам убежден, что после какой итерации "Зачем" всё сведется к чему-то иррациональному. Но это уже мое наблюдение как люди принимают решение. И да, лучше если задавать "Зачем" в диалоге - самому себе можно объяснить что угодно.
"Что же касается дискуссий, то единственная возможность победить – не участвовать совсем" - как бы логическая ошибка. Неучастие не равно победе. Можно, конечно, добавить, что такая цель и ставилась. Но в реале все по разным углам разведены. В целом, согласен. Добавлю, что проблема в том, что подразумевается "рациональный" спор, где цель - установление истины. Если расширить в нерациональное, где информация и истина вторичны, то и конфликта не наблюдаю. То есть в общении бывают не только ищущие правду, но и мошенники, и манипуляторы, и абьюзеры, и фанатики и др. И если с какими-то спорить опасно для себя, то с какими-то то не стоит спорить, потому что их мировоззрение развалится, а новое они не потянут.
Не спец конкретно в этой теме, но вижу одной из причин снижение горизонта планирования. Сейчас далеко вперед особо не планируют - там что-то с полки "фантастика". А управление знаниями, имхо, долгоиграющая тема.
Занудливо поправлю, что зависит от деятельности, графика работы, таланта/харизмы начальника, формализованности общения и так далее... Плюс вовлеченность начальника и степень делегирования. Например, если сеньор сам кодит, то времени меньше. Если общее управление, то времени больше. Классика управления говорит про 7-15 непосредственных подчиненных. Но если это бригада землекопов, то 35 норм. Также если скользящий график в 4 смены, то контролировать 50+ челов вполне реально.
В моём опыте - плохое или недоверительное общение между начальником и сотрудниками. Эмоции - сильно вторичный мотиватор,..
Мое мнение, что доверие выстраивается на свободе эмоций. И как раз мой опыт показывает, что эмоции первичны. Когда появляются эмоции - логика отваливается, потому более важны. Но эмоции сильно субъективны, и словами их трудно описать. Потому к отчету не пришить и бюджет не получить. Но важны во всех сферах жизни - и управление в том числе. 60+ человек - сложное управление, согласен про важность анонимной обратной связи в вашем случае.
Идею анонимной обратной связи я узнал в книге "Дедлайн" Тома ДеМарко много лет назад. Но тогда гугл-форм не было, рекомендовался почтовый ящик. Сейчас не понимаю, почему нельзя использовать почтовый ящик - можно же получить письмо не из корпоративной почты. В книге акцент делался на связывании топа с рядовыми сотрудниками - против фильтров и искажений сигналов в звеньях цепи управления. У вас вижу целью не сам проект, а систему мотивации. Тема обычная - сам как-то по молодости так ушел из отдела. Критика статьи: само присутствие анонимного опроса показывает, то обычное общение нарушено. Или сотрудники не могут сказать важное, или непосредственный начальник не контактен - то есть присутствуют проблемы системы управления. И опрос - это "предохранительный клапан", чтобы сбросить давление. Потеря одного сотрудника - просто расходы, а если весь отдел "встали и ушли", то руководитель с высокой вероятностью тоже уйдет, а проект протухнет. Если общение присутствует, то анонимность больше фарс. И, наоборот, польза сомнительна - сотрудники могут влиять на политику в своих интересах - "хвост управляет собакой". На мой взгляд - нужно добавлять эмоции в совещания. Имхо, основная проблема молчаливого ухода - отсутствие эмоций в работе. Ну и анек в тему: После корпоративной игры в пейнтбол начальника легко узнать по тому, что на нём есть следы не только от краски, но ещё и от прикладов.
Металлургия - это массовое производство. Экономика весьма специфичная. И здесь чугуний. А так вариантов - мильён. Сейчас модняво порошковые стали, и экономика тоже своя и позволяет.
Денис, не было задачи объять необъятное. Могут быть и полярные варианты: сервер без фронта, сайт без бэка. Здесь ИМХО, что вход во фронт был для меня тяжелее даже с опытом ворда и 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 псевдопричины-отмазки кончаются, и остается раздетая правда типа "с новой игрушкой жизнь будет ярче".
Здесь в статье про как бы рациональное бизнес-поведение. Но я сам убежден, что после какой итерации "Зачем" всё сведется к чему-то иррациональному. Но это уже мое наблюдение как люди принимают решение.
И да, лучше если задавать "Зачем" в диалоге - самому себе можно объяснить что угодно.
Имхо, вы поторопились с комментом. Или я не понял вопроса. Или вообще где мы расходимся в позиции?
"Что же касается дискуссий, то единственная возможность победить – не участвовать совсем" - как бы логическая ошибка. Неучастие не равно победе. Можно, конечно, добавить, что такая цель и ставилась. Но в реале все по разным углам разведены.
В целом, согласен. Добавлю, что проблема в том, что подразумевается "рациональный" спор, где цель - установление истины. Если расширить в нерациональное, где информация и истина вторичны, то и конфликта не наблюдаю. То есть в общении бывают не только ищущие правду, но и мошенники, и манипуляторы, и абьюзеры, и фанатики и др. И если с какими-то спорить опасно для себя, то с какими-то то не стоит спорить, потому что их мировоззрение развалится, а новое они не потянут.
Не спец конкретно в этой теме, но вижу одной из причин снижение горизонта планирования. Сейчас далеко вперед особо не планируют - там что-то с полки "фантастика". А управление знаниями, имхо, долгоиграющая тема.
Занудливо поправлю, что зависит от деятельности, графика работы, таланта/харизмы начальника, формализованности общения и так далее... Плюс вовлеченность начальника и степень делегирования. Например, если сеньор сам кодит, то времени меньше. Если общее управление, то времени больше.
Классика управления говорит про 7-15 непосредственных подчиненных. Но если это бригада землекопов, то 35 норм. Также если скользящий график в 4 смены, то контролировать 50+ челов вполне реально.
Мое мнение, что доверие выстраивается на свободе эмоций. И как раз мой опыт показывает, что эмоции первичны. Когда появляются эмоции - логика отваливается, потому более важны. Но эмоции сильно субъективны, и словами их трудно описать. Потому к отчету не пришить и бюджет не получить. Но важны во всех сферах жизни - и управление в том числе.
60+ человек - сложное управление, согласен про важность анонимной обратной связи в вашем случае.
Идею анонимной обратной связи я узнал в книге "Дедлайн" Тома ДеМарко много лет назад. Но тогда гугл-форм не было, рекомендовался почтовый ящик. Сейчас не понимаю, почему нельзя использовать почтовый ящик - можно же получить письмо не из корпоративной почты. В книге акцент делался на связывании топа с рядовыми сотрудниками - против фильтров и искажений сигналов в звеньях цепи управления.
У вас вижу целью не сам проект, а систему мотивации. Тема обычная - сам как-то по молодости так ушел из отдела. Критика статьи: само присутствие анонимного опроса показывает, то обычное общение нарушено. Или сотрудники не могут сказать важное, или непосредственный начальник не контактен - то есть присутствуют проблемы системы управления. И опрос - это "предохранительный клапан", чтобы сбросить давление. Потеря одного сотрудника - просто расходы, а если весь отдел "встали и ушли", то руководитель с высокой вероятностью тоже уйдет, а проект протухнет.
Если общение присутствует, то анонимность больше фарс. И, наоборот, польза сомнительна - сотрудники могут влиять на политику в своих интересах - "хвост управляет собакой".
На мой взгляд - нужно добавлять эмоции в совещания. Имхо, основная проблема молчаливого ухода - отсутствие эмоций в работе.
Ну и анек в тему:
После корпоративной игры в пейнтбол начальника легко узнать по тому, что на нём есть следы не только от краски, но ещё и от прикладов.
Металлургия - это массовое производство. Экономика весьма специфичная. И здесь чугуний. А так вариантов - мильён. Сейчас модняво порошковые стали, и экономика тоже своя и позволяет.