Я правильно понимаю, что вы не читали статью?
«Перейти на OpenJDK, использовать только релизы с долгосрочной поддержкой, и устанавливать версии с исправленными ошибками, доступные для OpenJDK. Это жизнеспособное решение для компаний, которые не могут или не хотят менять стоимость инфраструктуры Java, могли обходиться без коммерческой поддержки в прошлом и полагают, что также смогут и в долгосрочной перспективе.»
Ну как, у нас сабмодуль — это полноценный репозиторий. В том плане, что если изменения в проекте требуют изменений в сабмодуле — делается отдельная ветка и там и там, два пулл реквеста и т. д. За счёт линейной истории конфликты сведены к минимуму. Грубо говоря, для проекта сабмодуль — это внешний компонент, и конфликт сводится к тому, что есть хэш, в котором реализована фича А, и есть хэш, в котором она не реализована, ничего сложного.
Проблемы с мержем сабмодулей, про которые вы говорите, за полтора года работы над этим проектом встречались раза два.
Как обычно, не вижу разницы, если честно. Фичи делаются в отдельных ветках, перед merge делаем rebase чтобы свести конфликты к минимуму, если какие-то ломающие изменения — то да, всем придётся править код, но только после принудительного обновления сабмодуля до мастера (т. е. ничего не ломается само по себе).
В проекте, над которым я работаю, мы используем submodule и каждая ветка основного проекта связана с конкретной веткой сабмодуля. Меняю ветку — сабмодуль тоже меняется, что я делаю не так?
Да, ничего не скажу про PCRE, но в регулярках .Net точно используются недетерминированные конечные автоматы в сложных случаях, может быть даже с магазином
Зря вы так, в этом деле надо без фанатизма — и тогда у всех всё будет хорошо. Насколько я помню, сторипоинты нужны в том числе для оценки фокус-фактора команды, да и никто же не требует от вас точной оценки — покер планнинг вроде бы должен повышать её точность, отчасти поэтому оценка в сторипоинтах, а не в часах.
Надеюсь, исправите в том числе и такой баг в приложении для android — при включенном приложении приходит перевод, а сумма остаётся прежней — т. е. чтобы перевести или оплатить что-нибудь, надо перезайти.
Хм, знаете, я замечаю такую интересную вещь — чем сильнее программист, тем более понятный его код.
К сожалению, это правило работает не всегда. Например, далеко не всякий код на C# с активным использованием Reflection (и особенно Reflection.Emit) будет понятен с ходу, даже если его написал крутой специалист.
Да, размер MTU выдаёт с потрохами. Таймзона сама по себе тоже не особо полезна — занимаюсь последние пару лет приложениями для VPN, пользователи, переводящие время, вызывают умиление :)
А ещё есть dns ip leak например.
Я же не говорю, что библиотекари, или слесари — плохие и ненужные люди.
Моя мысль в том, что они ну никак не вписываются в квалификацию джун/миддл/сеньор, в их прямые обязанности не входит написание кода, и сравнивать найм джунов в IT-компании с наймом библиотекарей/слесарей в IT-компании, как минимум, неверно.
Про библиотекарей совсем не в тему пример, джун — это в какой-то мере степень профессионального развития программиста, я не думаю, что библиотекарь или слесарь может считаться таковой.
«Перейти на OpenJDK, использовать только релизы с долгосрочной поддержкой, и устанавливать версии с исправленными ошибками, доступные для OpenJDK. Это жизнеспособное решение для компаний, которые не могут или не хотят менять стоимость инфраструктуры Java, могли обходиться без коммерческой поддержки в прошлом и полагают, что также смогут и в долгосрочной перспективе.»
Проблемы с мержем сабмодулей, про которые вы говорите, за полтора года работы над этим проектом встречались раза два.
К сожалению, это правило работает не всегда. Например, далеко не всякий код на C# с активным использованием Reflection (и особенно Reflection.Emit) будет понятен с ходу, даже если его написал крутой специалист.
А ещё есть dns ip leak например.
Моя мысль в том, что они ну никак не вписываются в квалификацию джун/миддл/сеньор, в их прямые обязанности не входит написание кода, и сравнивать найм джунов в IT-компании с наймом библиотекарей/слесарей в IT-компании, как минимум, неверно.