Вообще, мне кажется, что если есть какая-то вероятность десериализовать из нескольких разных форматах, то хорошо использовать какое-то промежуточное представление дерева, в который парсить и из которого разбирать.
Так получается, что есть у нас десятка три класса, умеющих разбираться из json. Светлым умам пришла идея читать из XML. В три десятка классов добавляем чтение? А потом плюс класс, добавляем в него две десериализации. Звучит грустно, если только вы не на почасовой оплате.
Но если очень надо всё делать в классе, то можно, наверное, так:
Если у нас вдруг добавится парсинг YAML? Тоже добавлять метод в класс? В идеале, конечно, иметь какую нибудь рефлексию и стандартные (де)сериализаторы в разные форматы. Но загрязнять класс парсингом из произвольных форматов, имхо, так себе вариант.
А зачем знать все места, где вызовется деструктор? Мы знаем правило, что когда закончится лайфтайм. Если где-то объект зависает, то это ж не проблема деструктор а.
Надо вначале попросить проградуировать шкалу, кого эталоном за 10, а кого за 1. От этого можно уже и себя оценивать. А так получается — оцените на глаз от 1 до 10 высоту вот этого здания.
И я не всегда проверяю досконально, что именно уходит в коммит, потому что я и так знаю, как я изменил репозиторий по сравнению с предыдущим состоянием. Исправил пару файлов, создал папку, нажал коммит в интерфейсе, все. Файлы ушли, папка нет.
Но это же как раз означает, что в реальности вы не знаете, как изменили репозиторий с предыдущим состоянием. Я тоже пару раз напарывался на то, что открыл проект в другой IDE, получил пачку файлов, которых я не создавал. После второго раза приучился смотреть, что реально пойдёт в репу.
Но я понял вашу точку зрения, вам, наверное, действительно нужны пустые папки. Спасибо за пример.
Откуда эти файлы берутся? Ну вот я новый разработчик, сделал git clone, получил пустую папку. Есть какие-то инструменты, которые а) что-то генерируют в папку и б) не умеют при этом папку создавать? Я не спорю, мне правда интересно, что это за инструментарий такой.
Простите, но ваш пример очень странный, я не знаю ни одного разработчика, который не делает перед комитом git status или аналог, чтоб посмотреть, что пойдет в комит. Поэтому как можно подумать, что папка ушла в репу, когда она при этом не ушла? Я просто исхожу из опыта (это конечно, не очень сильный аргумент), но за много лет ни разу не встречал ситуации, когда нужна была пустая папка (проекты c++/Java/go). У вас был не гипотетический, а реальный случай, когда она понадобилась?
С одной стороны вы, конечно, правы, инструмент по хорошему должен позволять делать так, как удобнее работать. Но с другой стороны, должен ли позволять багтрекер, например, создавать тикет без заголовка и описания? Кому-то это может быть удобно, но в общем случае это вредно.
С договорами для клиентов все, имхо, просто: появился клиент, сложили шаблон с реквизитами юрлица. И папка не пустая, и смысл в ней появился.
Вы какие-то сгенерированные файлы в source-tree складываете? А что с ними потом делать? Все равно придётся как-то их вычистить, чтоб папка осталась пустой. Опять какой-то скрипт
С одной стороны, это лишние слова. С другой — никто не заставит так писать везде, компилятор по рукам не надаёт, так что обязательно найдётся кто-то, кто this писать не будет. Получится каша. Префикс в этом отношении лучше, один раз написал, все остальные при использовании его тоже напишут.
Мне кажется, это несколько не то, что хочется. Допустим, есть три переменные, каждая из которых принимает 3 значения. Допустима любая комбинация. Это надо 27 расписаний создавать, или я идею не уловил?
Некоторые вещи, на раз-два делающиеся в Jenkins очень сложно сделать в Gitlab. Например, набор комбобоксов с выбором опций сборки (Debug/Release; gcc/clang и т.д.). Можно, конечно, руками все переменные прописать, но это надо постоянно помнить, какие именно переменные и значения подставлять. Или в Gitlab есть какой-нибудь способ сделать это без боли?
В 2019 году довелось проехать 30+ штатов. Основной источник питания Walmart. Кус-кус был почти везде. Разный рис тоже. Яблоки и манго постоянно, также из овощей всегда брали салат и капусту. Хлеб есть как ватный, так и нормальный свежевыпеченный. Пожалуй, самый поганый Walmart был в Чикаго, остальные более-менее одинаковые по ассортименту.
Так мы ж тут про репутацию компании говорим. В одной стриптизерши для развлечения программистов выписываются, в другой туалет на этаже три месяца починить не могут, ходите в соседнее здание. Ни первый, ни второй случай при трудоустройстве не обговаривается, но ощущение оставляет разное. Понятное дело, что вариант слёзно жаловаться — так себе идея. Но почему нельзя послушать опыт других людей, которые попробовали и ушли, без "сам лох, не сумел себя поставить, а так то тебе вообще никто ничего не должен"?
А если это приходится делать постоянно? Я не очень понимаю, почему может быть нормально, что некоторые вещи требуется добывать, и это может считаться плюсом компании (я не про какую-то конкретную).
Сломался у тебя офисный стул. В компании, где нет "доброго дяди" будь добр не только оставь заявку на новую мебель, но ещё задолбай всех, что она тебе действительно нужна, и проконтролируй, чтоб её тебе донесли. Смонтировать, конечно, самостоятельно.
Летишь в командировку. "Доброго дяди" нет, поэтому билеты ищи сам, гостиницу бронируй сам, и далее по списку.
Проходишь все PR с высокими оценками и озвучиваешь своё желание о повышении компенсации. В компании без "доброго дяди" не забудь ещё переговорить в курилке с десятком различных менеджеров, пару раз станцевать и принести офер от другой компании с суммой x1.5.
Так что может быть человек, который должен решать за меня часть проблем в здоровой компании всё таки существует?
Можно другой пример привести: приходишь ты в булочную и тебе дают позавчерашнюю булку, чёрствую и немного с плесенью. Второй человек пришёл, пересмотрел все доступные булки, поругался, поторговался и получил свежевыпеченную. С одной стороны, каждый сам кузнец своего счастья, хочешь свежую булку — ругайся с булочной. Но скажем ли мы при этом, что это хорошая булочная?
Вообще, мне кажется, что если есть какая-то вероятность десериализовать из нескольких разных форматах, то хорошо использовать какое-то промежуточное представление дерева, в который парсить и из которого разбирать.
Так получается, что есть у нас десятка три класса, умеющих разбираться из json. Светлым умам пришла идея читать из XML. В три десятка классов добавляем чтение? А потом плюс класс, добавляем в него две десериализации. Звучит грустно, если только вы не на почасовой оплате.
Но если очень надо всё делать в классе, то можно, наверное, так:
Зачем обязательно передавать строку?
Если у нас вдруг добавится парсинг YAML? Тоже добавлять метод в класс? В идеале, конечно, иметь какую нибудь рефлексию и стандартные (де)сериализаторы в разные форматы. Но загрязнять класс парсингом из произвольных форматов, имхо, так себе вариант.
А зачем знать все места, где вызовется деструктор? Мы знаем правило, что когда закончится лайфтайм. Если где-то объект зависает, то это ж не проблема деструктор а.
Есть strong typedef.
Надо вначале попросить проградуировать шкалу, кого эталоном за 10, а кого за 1. От этого можно уже и себя оценивать. А так получается — оцените на глаз от 1 до 10 высоту вот этого здания.
Но это же как раз означает, что в реальности вы не знаете, как изменили репозиторий с предыдущим состоянием. Я тоже пару раз напарывался на то, что открыл проект в другой IDE, получил пачку файлов, которых я не создавал. После второго раза приучился смотреть, что реально пойдёт в репу.
Но я понял вашу точку зрения, вам, наверное, действительно нужны пустые папки. Спасибо за пример.
Откуда эти файлы берутся? Ну вот я новый разработчик, сделал git clone, получил пустую папку. Есть какие-то инструменты, которые а) что-то генерируют в папку и б) не умеют при этом папку создавать? Я не спорю, мне правда интересно, что это за инструментарий такой.
Простите, но ваш пример очень странный, я не знаю ни одного разработчика, который не делает перед комитом git status или аналог, чтоб посмотреть, что пойдет в комит. Поэтому как можно подумать, что папка ушла в репу, когда она при этом не ушла? Я просто исхожу из опыта (это конечно, не очень сильный аргумент), но за много лет ни разу не встречал ситуации, когда нужна была пустая папка (проекты c++/Java/go). У вас был не гипотетический, а реальный случай, когда она понадобилась?
С одной стороны вы, конечно, правы, инструмент по хорошему должен позволять делать так, как удобнее работать. Но с другой стороны, должен ли позволять багтрекер, например, создавать тикет без заголовка и описания? Кому-то это может быть удобно, но в общем случае это вредно.
С договорами для клиентов все, имхо, просто: появился клиент, сложили шаблон с реквизитами юрлица. И папка не пустая, и смысл в ней появился.
Вы какие-то сгенерированные файлы в source-tree складываете? А что с ними потом делать? Все равно придётся как-то их вычистить, чтоб папка осталась пустой. Опять какой-то скрипт
А зачем пустую папку комитить?
Ну а для версионирования сабмодули можно использовать.
На cmake можно собрать и настроить что угодно. Но поддерживать эти тонны скриптов более-менее крупного проекта это боль.
С одной стороны, это лишние слова. С другой — никто не заставит так писать везде, компилятор по рукам не надаёт, так что обязательно найдётся кто-то, кто this писать не будет. Получится каша. Префикс в этом отношении лучше, один раз написал, все остальные при использовании его тоже напишут.
Мне кажется, это несколько не то, что хочется. Допустим, есть три переменные, каждая из которых принимает 3 значения. Допустима любая комбинация. Это надо 27 расписаний создавать, или я идею не уловил?
Некоторые вещи, на раз-два делающиеся в Jenkins очень сложно сделать в Gitlab. Например, набор комбобоксов с выбором опций сборки (Debug/Release; gcc/clang и т.д.). Можно, конечно, руками все переменные прописать, но это надо постоянно помнить, какие именно переменные и значения подставлять. Или в Gitlab есть какой-нибудь способ сделать это без боли?
В 2019 году довелось проехать 30+ штатов. Основной источник питания Walmart. Кус-кус был почти везде. Разный рис тоже. Яблоки и манго постоянно, также из овощей всегда брали салат и капусту. Хлеб есть как ватный, так и нормальный свежевыпеченный. Пожалуй, самый поганый Walmart был в Чикаго, остальные более-менее одинаковые по ассортименту.
Так мы ж тут про репутацию компании говорим. В одной стриптизерши для развлечения программистов выписываются, в другой туалет на этаже три месяца починить не могут, ходите в соседнее здание. Ни первый, ни второй случай при трудоустройстве не обговаривается, но ощущение оставляет разное. Понятное дело, что вариант слёзно жаловаться — так себе идея. Но почему нельзя послушать опыт других людей, которые попробовали и ушли, без "сам лох, не сумел себя поставить, а так то тебе вообще никто ничего не должен"?
А если это приходится делать постоянно? Я не очень понимаю, почему может быть нормально, что некоторые вещи требуется добывать, и это может считаться плюсом компании (я не про какую-то конкретную).
Сломался у тебя офисный стул. В компании, где нет "доброго дяди" будь добр не только оставь заявку на новую мебель, но ещё задолбай всех, что она тебе действительно нужна, и проконтролируй, чтоб её тебе донесли. Смонтировать, конечно, самостоятельно.
Летишь в командировку. "Доброго дяди" нет, поэтому билеты ищи сам, гостиницу бронируй сам, и далее по списку.
Проходишь все PR с высокими оценками и озвучиваешь своё желание о повышении компенсации. В компании без "доброго дяди" не забудь ещё переговорить в курилке с десятком различных менеджеров, пару раз станцевать и принести офер от другой компании с суммой x1.5.
Так что может быть человек, который должен решать за меня часть проблем в здоровой компании всё таки существует?
Можно другой пример привести: приходишь ты в булочную и тебе дают позавчерашнюю булку, чёрствую и немного с плесенью. Второй человек пришёл, пересмотрел все доступные булки, поругался, поторговался и получил свежевыпеченную. С одной стороны, каждый сам кузнец своего счастья, хочешь свежую булку — ругайся с булочной. Но скажем ли мы при этом, что это хорошая булочная?
KDE точно умеет. Вот только что проверил. Из-за это правда не работает выделение в столбик с зажатым Alt.