Если я правильно знаю, то это как раз источник, а не агрегатор. Организаторы напрямую размещают анонсы мероприятий в системе. Плюс заявки спортсменов, и выгрузка заявок в программы хронометрии соревнований. Разработка кого-то из ориентирования, то есть под ориентировщиков заточено. Потом уже остальные добавились. Ваш список тоже любопытен - иногда тянет что-то новое сфотографировать.
Добречкого. Не знаю ни одного из перечисленных сайтов, потому что есть orgeo.ru. Больше про спортивное ориентирование или спортивный туризм, но и другие виды присутствуют.
Уважительное с определенными интонациями, которые отражают Большое Уважение в редких случаях официального и личного обращения. ВО ВСЕХ ДРУГИХ случаях достаточно маленького "вы".
Царапнуло глаз "прошу Вас..." - по правилам русского языка достаточно вас с маленькой буквы. Большое "Вы" - в очень редких случаях, точно не про внутреннюю переписку. По теме выделил бы основную проблему - вам не отвечают! Далее куча вариантов... В первую очередь - должны ли вам вообще отвечать?! Если ваши вопросы могут игнорировать - они будут проигнорированы. Это нормально, потому что: 1) работа, 2) лишние контакты отвлекают, 3) частичный ответ или ответ не в тему могут усугубить проблему. Если "должны отвечать" - то это локальная задача управления. В первую очередь вам дается ответственность за какой-то спектр задач и полномочия требовать информацию. Далее - разумный срок ответа. Если ответа нет, то обращаться к непосредственному начальнику. Если проблема не решена - уровнем выше. И здесь речь не про токсичность, а про то, что у вас простой в задаче, за которую вы получаете зарплату. А отсутствие срока какой-то работы весьма вероятно указывает на какую-то проблему, которую должен решать уже другой уровень управления. З.Ы. в примере приторного письма зубодробительная канцелярщина - 5 баллов из 5!
Все началось с того, что я в очередной раз немного поменял...
Лучшее начало статьи - сохраню себе в памятку! очень открывательная строка. Уверен, что с этого начинаются все увлекательные приключения!.. Пардонюсь за оффтопик, тесты еще надкусываю, тут две статьи подряд погрызть.
Смело написать такое в публичное и циничное пространство. Уважаю. Поддержать не смогу. Сколько людей - столько и диагнозов. Тем более ставить их в интернете - это 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, если память не подводит.
В зависимости от интенсивности расходов. Сейчас просто за неделю посмотреть историю по карте. А раньше с наличкой приходилось сильно чаще открывать записи. Знаю, что кто-то просто на бумажке в кармане записывал кому и сколько заплатил, чтобы к вечеру не забыть. Полезный багаж - выучить бухучет (в википедии можно много узнать). К началу своего учета я уже вел управленческий учет на малом предприятии, потому "двойная запись" и "баланс" для меня были открытой книгой.
Если я правильно знаю, то это как раз источник, а не агрегатор. Организаторы напрямую размещают анонсы мероприятий в системе. Плюс заявки спортсменов, и выгрузка заявок в программы хронометрии соревнований. Разработка кого-то из ориентирования, то есть под ориентировщиков заточено. Потом уже остальные добавились.
Ваш список тоже любопытен - иногда тянет что-то новое сфотографировать.
Добречкого. Не знаю ни одного из перечисленных сайтов, потому что есть orgeo.ru. Больше про спортивное ориентирование или спортивный туризм, но и другие виды присутствуют.
Уважительное с определенными интонациями, которые отражают Большое Уважение в редких случаях официального и личного обращения. ВО ВСЕХ ДРУГИХ случаях достаточно маленького "вы".
Царапнуло глаз "прошу Вас..." - по правилам русского языка достаточно вас с маленькой буквы. Большое "Вы" - в очень редких случаях, точно не про внутреннюю переписку.
По теме выделил бы основную проблему - вам не отвечают! Далее куча вариантов... В первую очередь - должны ли вам вообще отвечать?! Если ваши вопросы могут игнорировать - они будут проигнорированы. Это нормально, потому что: 1) работа, 2) лишние контакты отвлекают, 3) частичный ответ или ответ не в тему могут усугубить проблему.
Если "должны отвечать" - то это локальная задача управления. В первую очередь вам дается ответственность за какой-то спектр задач и полномочия требовать информацию. Далее - разумный срок ответа. Если ответа нет, то обращаться к непосредственному начальнику. Если проблема не решена - уровнем выше.
И здесь речь не про токсичность, а про то, что у вас простой в задаче, за которую вы получаете зарплату. А отсутствие срока какой-то работы весьма вероятно указывает на какую-то проблему, которую должен решать уже другой уровень управления.
З.Ы. в примере приторного письма зубодробительная канцелярщина - 5 баллов из 5!
Промахнулись с названием. SkyNet - имя ему. Походу на авторские права поскупились.
Лучшее начало статьи - сохраню себе в памятку! очень открывательная строка. Уверен, что с этого начинаются все увлекательные приключения!.. Пардонюсь за оффтопик, тесты еще надкусываю, тут две статьи подряд погрызть.
Смело написать такое в публичное и циничное пространство. Уважаю. Поддержать не смогу. Сколько людей - столько и диагнозов. Тем более ставить их в интернете - это 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, если память не подводит.
В зависимости от интенсивности расходов. Сейчас просто за неделю посмотреть историю по карте. А раньше с наличкой приходилось сильно чаще открывать записи. Знаю, что кто-то просто на бумажке в кармане записывал кому и сколько заплатил, чтобы к вечеру не забыть.
Полезный багаж - выучить бухучет (в википедии можно много узнать). К началу своего учета я уже вел управленческий учет на малом предприятии, потому "двойная запись" и "баланс" для меня были открытой книгой.