Я 10 лет проработала танцовщицей go go в ночных клубах
<шутка юмора>Надо было не в php-разработчики идти, а в go-разработчики</шутка юмора>
Вы молодец. Очень круто, что смогли сменить род профессиональной деятельности. Не всем под силу это, когда уже не 18 лет. Я вот чувствую, что в свои 31 всё больше и больше костенею в своих возможностях меняться.
Главное — не останавливаться на достигнутом, постоянно читать профессиональную литературу, стремиться понимать свою профессию «вглубь», а не «в ширину».
Насчёт схем формата, вынесенных в отдельный файл, наподобие xsd, я не задавался пока что таким вопросом, т.к. это было бы усложнение задачи поддержки конфигов. Нам в любом случае надо было бы и в коде поддерживать соответствие "такое-то поле мы используем вот здесь". Т.е. для добавления нового поля, например, нам потребовалось бы сделать это в xml, в xsd и в коде. Сейчас мы обходимся только добавлением в yml и в коде. Не вижу смысла усложнять работу
В статье как раз описывается как реализована проверка полноты и корректности конфига. Ошибки yaml синтаксиса вываливает yaml-читалка, а ошибки вида "не хватает такого-то параметра" или "этот параметр я не знаю" вываливает наш код. Описание формата у нашего кода конечно же есть, иначе зачем нам вообще этот конфиг, если мы не знаем, что из него брать. См. класс AppSettings в статье.
Централизованный сервис мы тоже рассматриваем.
XML не «плоский», плоская та структура, которую мы ранее для него предусматривали. Реализовать в нем вложенную структуру, конечно же, вполне можно было, но монструозность конфигов сильно увеличилась бы.
Получившиеся у нас сейчас конфиги хорошо читаются глазами.
Т.е. вместо XML-ки с конфигами поддерживать еще и XSD-схемы для каждого вида серверов? Это усложнение работы, а не ее упрощение.
В решении с YAML в том виде, как оно реализовано, получилось реальное упрощение чтения конфига глазами + более прозрачная работа парсера, вываливающая все встречающиеся ошибки явным образом.
Раньше парсер проглатывал несуществующие (неправильно написанные) тэги. Сейчас этого не происходит в силу предложенного решения сопоставлений ожидаемого конфига и файла-конфига «один-к-одному».
У нас чтение производилось с использованием XmlDocument, он в половине случаев опечатки молча проглатывал (если честно — не помню хотя бы раза, когда он не проглатил бы). Какие конкретно примеры — сходу не подскажу, посмотрю потом при случае.
В других проектах у нас конфиги были и есть на YAML, по нему отзывы были положительные: достаточно удобно читать и редактировать. Размеры файлов там разные, по несколько сотен строк тоже есть, но чаще — несколько десятков. Поэтому решили опробовать его и здесь.
В этом проекте после перехода на YAML лично у меня тоже скорее положительные ощущения. Конфиги стали сильно меньше, опечатки в них исчезли, все проблемы стали видны сразу на старте приложения. Единственный сайд-эффект, который я пока наблюдал, то, что по началу табы, которые иногда получались вместо пробелов, портили чтение файла, но это не большая проблема, т.к. такие ошибки, как я уже сказал, сразу же всплывали на старте сервиса, плюс сама проблема достаточно легко решилась настройкой в редакторе.
XML — далеко не единственное, что держит нас пока что от полного перехода на .NET Core всех серверов, хотя мы движемся в этом направлении. Сам по себе XML — да, не стопер.
При этом у читалки XML из стандартного пакета есть проблемы, которые в принципе усложняют работу с ним, связанные прежде всего с плохой реакцией на опечатки в XML (которые в силу многословности XML не так уж редки), которые как раз дополнительно простимулировали нас уходить от него.
Читалку из .NETStandard для XML мы, честно скажу, не проверяли. У нее с обработкой опечаток дела обстоят лучше?
Consul и т.п. сервисы — да, была такая идея, и она, собственно говоря, никуда не делась, в будущем вполне возможно перейдем на какое-то единое решение, которое, кроме прочего, позволит конфигурировать не только указанные 12 серверов, но и все остальные сервисы, разрабатываемые у нас в компании. Но прямо сейчас это потребовало бы, по ощущениям, сильно больше телодвижений, чем просто выкинуть один способ работы с файликами конфигурации и заменить его на другой, всё остальное трогать нам сейчас не пришлось.
Мне кажется, от джуна главное — это:
а) базовый уровень знаний по нужному языку,
б) умение и желание учиться.
Некоторые из этих вопросов шире базового уровня знаний, как мне кажется.
Ничего себе как джуна штудируют…
Я бы не ответил сходу про вызов из дочернего класса другого метода базового класса, если он тоже переопределен. Возможно, надо скастить к типу базового класса. Но не факт. А вот то, что факт — это то, что, если у них реально такой код, то у них большие проблемы с архитектурой и те ещё костыли по коду. Так что звоночек не в пользу компании как раз.
У Вас ошибка на сайте — стабильно ничего не делает (не обрабатывает загруженное фото), если пытаться загрузить второе фото подряд без перезагрузки страницы. Т.е.
1) Загружаем первое фото
2) Смотрим результат
3) Пытаемся загрузить второе фото — ничего не происходит (список не перестраивается).
После второго шага из-за этого приходится каждый раз перезагружать страницу (F5).
У нас не мобильное приложение (хотя эти продукты, конечно, на них направлены), у нас сервера, базы которых (используемые только на чтение) должны синхронизироваться с другой базой (используемой на запись).
В техподдержку не обращались. Так как кафка уже использовалась в других наших системах, мы решили просто перейти на нее и в этом продукте.
Странно. У нас в проекте couchbase вообще не прижился, пришлось отказаться в пользу кафки.
Проблема была в том, что couchbase lite периодически (достаточно часто) впадал в странное состояние, когда он должен синкаться с syncgateway, но по факту синхронизации не происходит. Помогал только рестарт клиента.
Танцы с бубнами не помогли, решили что дешевле отказаться от него
Странно, что при этом ни разу не упоминается ни название, ни иные принципы TDD (именно так называется этот подход). Но статья мне понравилась, посыл верный
V3083 (возможный NRE при вызове евента) — попробуйте всегда использовать myevent?.Invoke(...) — о подобных проблемах не придётся думать.
Вопрос — были ли у вас дубли с предупреждениями решарпера?
<шутка юмора>Надо было не в php-разработчики идти, а в go-разработчики</шутка юмора>
Вы молодец. Очень круто, что смогли сменить род профессиональной деятельности. Не всем под силу это, когда уже не 18 лет. Я вот чувствую, что в свои 31 всё больше и больше костенею в своих возможностях меняться.
Главное — не останавливаться на достигнутом, постоянно читать профессиональную литературу, стремиться понимать свою профессию «вглубь», а не «в ширину».
Описание "ожидаемого содержимого конфига", а не формата, имел в виду
Насчёт схем формата, вынесенных в отдельный файл, наподобие xsd, я не задавался пока что таким вопросом, т.к. это было бы усложнение задачи поддержки конфигов. Нам в любом случае надо было бы и в коде поддерживать соответствие "такое-то поле мы используем вот здесь". Т.е. для добавления нового поля, например, нам потребовалось бы сделать это в xml, в xsd и в коде. Сейчас мы обходимся только добавлением в yml и в коде. Не вижу смысла усложнять работу
В статье как раз описывается как реализована проверка полноты и корректности конфига. Ошибки yaml синтаксиса вываливает yaml-читалка, а ошибки вида "не хватает такого-то параметра" или "этот параметр я не знаю" вываливает наш код. Описание формата у нашего кода конечно же есть, иначе зачем нам вообще этот конфиг, если мы не знаем, что из него брать. См. класс AppSettings в статье.
XML не «плоский», плоская та структура, которую мы ранее для него предусматривали. Реализовать в нем вложенную структуру, конечно же, вполне можно было, но монструозность конфигов сильно увеличилась бы.
Получившиеся у нас сейчас конфиги хорошо читаются глазами.
В решении с YAML в том виде, как оно реализовано, получилось реальное упрощение чтения конфига глазами + более прозрачная работа парсера, вываливающая все встречающиеся ошибки явным образом.
В этом проекте после перехода на YAML лично у меня тоже скорее положительные ощущения. Конфиги стали сильно меньше, опечатки в них исчезли, все проблемы стали видны сразу на старте приложения. Единственный сайд-эффект, который я пока наблюдал, то, что по началу табы, которые иногда получались вместо пробелов, портили чтение файла, но это не большая проблема, т.к. такие ошибки, как я уже сказал, сразу же всплывали на старте сервиса, плюс сама проблема достаточно легко решилась настройкой в редакторе.
При этом у читалки XML из стандартного пакета есть проблемы, которые в принципе усложняют работу с ним, связанные прежде всего с плохой реакцией на опечатки в XML (которые в силу многословности XML не так уж редки), которые как раз дополнительно простимулировали нас уходить от него.
Читалку из .NETStandard для XML мы, честно скажу, не проверяли. У нее с обработкой опечаток дела обстоят лучше?
Consul и т.п. сервисы — да, была такая идея, и она, собственно говоря, никуда не делась, в будущем вполне возможно перейдем на какое-то единое решение, которое, кроме прочего, позволит конфигурировать не только указанные 12 серверов, но и все остальные сервисы, разрабатываемые у нас в компании. Но прямо сейчас это потребовало бы, по ощущениям, сильно больше телодвижений, чем просто выкинуть один способ работы с файликами конфигурации и заменить его на другой, всё остальное трогать нам сейчас не пришлось.
Игра на светлой стороне
а) базовый уровень знаний по нужному языку,
б) умение и желание учиться.
Некоторые из этих вопросов шире базового уровня знаний, как мне кажется.
Ничего себе как джуна штудируют…
Я бы не ответил сходу про вызов из дочернего класса другого метода базового класса, если он тоже переопределен. Возможно, надо скастить к типу базового класса. Но не факт. А вот то, что факт — это то, что, если у них реально такой код, то у них большие проблемы с архитектурой и те ещё костыли по коду. Так что звоночек не в пользу компании как раз.
1) Загружаем первое фото
2) Смотрим результат
3) Пытаемся загрузить второе фото — ничего не происходит (список не перестраивается).
После второго шага из-за этого приходится каждый раз перезагружать страницу (F5).
У меня Chrome.
У нас не мобильное приложение (хотя эти продукты, конечно, на них направлены), у нас сервера, базы которых (используемые только на чтение) должны синхронизироваться с другой базой (используемой на запись).
В техподдержку не обращались. Так как кафка уже использовалась в других наших системах, мы решили просто перейти на нее и в этом продукте.
Странно. У нас в проекте couchbase вообще не прижился, пришлось отказаться в пользу кафки.
Проблема была в том, что couchbase lite периодически (достаточно часто) впадал в странное состояние, когда он должен синкаться с syncgateway, но по факту синхронизации не происходит. Помогал только рестарт клиента.
Танцы с бубнами не помогли, решили что дешевле отказаться от него
Странно, что при этом ни разу не упоминается ни название, ни иные принципы TDD (именно так называется этот подход). Но статья мне понравилась, посыл верный
Вопрос — были ли у вас дубли с предупреждениями решарпера?