Я возмоно пропустил это, но почему нельзя использовать маркерные интерфейсы?
Два интерфейса с операциями (Read, Write), один маркерный (Immutable), оригинальный List (extends Read, Write), и нужный ImmutableList (extends Read, Immutable).
Хороший пример, что не популярный язык использовать не надо. Ресурс ориентирован на русскоязычную аудиторию. Знания и использование эсперанто, топикона и других искуственных языков допустимо только в топика, посвященных им. Признак культуры говорящего человека, опять таки, говорить на языке окружающего социума.
С мовой иди в другое место.
Постоянно использовать смайлики, коверкать слова, игнорировать правила русского языка. Даже если русский язык был не самым вашим любимым предметом в школе или не является родным — проверка орфографии в браузере у вас наверняка есть, не стоит ею пренебрегать. Это сохранит как вашу карму от минусов, так и ваш аккаунт.
Спасибо за ответ!
Да, именно похожую схему я сейчас и прорабатываю:
Каждая функциональность ведется в отдельной бранче от «свежего» мастера.
Feature бранч может содержать несколько логических коммитов, но конечно желательно, чтобы это был один коммит.
На каждый коммит автоматически создается тикет на ревью с ключевыми ревьюверами.
(?) Мои ограничения позволяют мне использовать gitlab, так что я думаю попробовать его protected branches и git hooks, благо что какой-то Api у UpSource есть.
Я может быть не достаточно глубоко копал, но все же (возможно и не правильно) сравниваю апсорс с герритом. У геррита есть очень приятная мне вещь, отсутвующая в апсорсе: блокировка коммита, пока он не пройдет код ревью. Очень хочется не допускать попадания непроверенного кода в основную (master/develop) ветку из ветки фичи. Пока же получается только создавать принудительные тикеты на код ревью, но ответственность следить за их прохождением полностью ложится на автора коммита. Я видел issue по добавлению repository managment функциональности в upsource, можно надеяться ли что они решит эту проблему. И если да, то есть какой roadmap, чтобы увидеть ее поскорее?
Вертел я тебя с твоим JSON-омЯ очень ценю ваш опыт и рациональное предложение по поводу выбора технологии транспорта. Ваши аргументы хорошо подходят под текущие требования системы. Расскажи мне, мля, как ты будешь валидировать и трансформировать большие куски данных. Но мы бы хотели оставить место для предстоящего нового релиза, где нам предстоит интегрироваться с существующей бизнес системой заказчика, за которую он IBM отвалил пару миллионов бабосиков.
С уважением, ваш менеджер а ты хипстер и школьник
зыж Не принимать на персональнии, все совпадения случайны.
😂😂 супер. Но в целом да.
Два интерфейса с операциями (Read, Write), один маркерный (Immutable), оригинальный List (extends Read, Write), и нужный ImmutableList (extends Read, Immutable).
Правда, что-ли?
Постоянно использовать смайлики, коверкать слова, игнорировать правила русского языка. Даже если русский язык был не самым вашим любимым предметом в школе или не является родным — проверка орфографии в браузере у вас наверняка есть, не стоит ею пренебрегать. Это сохранит как вашу карму от минусов, так и ваш аккаунт.
Да, именно похожую схему я сейчас и прорабатываю:
А речь я вел про вот это UP-1730.
Слышь ты,Здравствуйте, Genka,Вертел я тебя с твоим JSON-омЯ очень ценю ваш опыт и рациональное предложение по поводу выбора технологии транспорта. Ваши аргументы хорошо подходят под текущие требования системы.Расскажи мне, мля, как ты будешь валидировать и трансформировать большие куски данных.Но мы бы хотели оставить место для предстоящего нового релиза, где нам предстоит интегрироваться с существующей бизнес системой заказчика,за которую он IBM отвалил пару миллионов бабосиков.С уважением, ваш менеджер
а ты хипстер и школьникзыж Не принимать на персональнии, все совпадения случайны.
> :)
Я про открытые источники, конечно же. :)
Есть ли отдел по «посдматриванию» за Амазоном и их решениями?
Ну так-то и есть, пример не то чтобы дурацкий, скорее отвратительный.