Что то 4 пункта преимуществ не имеют ни одного технического реально важного аспекта )))) главное что должна делать модель - писать код. Если она не может этого делать, а гига код не может даже близко, не важно какой язык она понимает и с каким Легаси работает
Тест на нахождение 10 непохожих существительных доказывает не креативность, а умение моделей решать стандартные задачи по семантическому анализу больших текстов. Так что слово креативность тут чисто для Хайпа.
И как блин у людей поворачивается палец поставить ChatGPT рядом с YandexGPT/GigaChat, который сыпется на любой реальной алгоритмической задаче, где добавлено дополнительное условие.
И почему тут нет Qwen, который на программировании себя реально лучше показывает. Я лично уже давно понял, что он лучше.
В работе используем ChatGPT. Ржом дружно даже с него, когда надо сделать, что-то кроме тупой алгоритмики или отрисовки гуев. Дома для себя Qwen. Yandex и Giga вообще думать не умеют. Чисто поисковики с эмууляцией контекста.
Удачи тем кто верит, что нейросети проживут без присмотра десятка матёрых спецов в своей области ) В бизнес логике так и подавно нейронки загонят в мир иллюзий своего владельца. А потом придется разгребать
Картинки, видосики, диспетчера и первая линия поддержки, консультант по архитектуре кода. Вот реальный предел текущих моделей.
Чтобы через год заявить, что если компания хочет сохранить все свои ИТ преференции все сотрудники должны быть сертифицированы. И начать рубить бабло из воздуха
Последние три года они как с цепи сорвались. Давайте без разбора лочить иностранных конкурентов - пофиг на то что бизнес страдает. Теперь будем паковать воздух (тесты) в банки и продавать его (требование закона на прохождение тестов)
Если по пунктам разложить все плюсы и минусы приведенные в статье. То побороть минусы корпорации проще чем минусы мелких кампаний. Работал и там и там и вернулся в Корпорацию. Почему?
Корпорации часто запускают мощные инфраструктурные проекты и так как культура ВСЕХ гигантов крайне высока, то новые проекты всегда запускаются на самом высшем уровне - кубер в клауде и иже с ними. Более того, тебя ещё будут мониторить и прессовать, что ты лисапэды изобретатешь. Так как все эти центры компетенции, над которыми многие смеются - они работают и там сидят реальные мозги, а не бюрократы. А ругают такие центры только вечные джуны/мидлы.
Итого. Хотим экспериментов, реализации идей и атмосферы ИТ - идем в молодой проект корпорации и бреем НН, которые зовут в старые проекты на Легаси. Главное уметь отказывать даже на самые вкусные проекты. Ибо даже в Яндексе есть всякие болота вроде HR-Tech (в народе HR течь).
Но готовимся к перссу высшего уровня, так как будут требовать подхода современного. Полного покрытия тестами, мокирования, контейнеризации и т.п (привожу просто так набор терминов, которые критически важны в современном мире, но увы не все понимают суть их), конкретика в виде технологий не так важна - они у всех разные. Причем без компромиссов. MVP не прокатит.
ПЫСЫ. Почему ответил - отвечаю редко. Не люблю категоричность и путаницу в причино следственных связях. В корпорациях тоже можно побороть все минусы и остаться только с плюсами, просто надо показать что ты можешь. Там отбор выше ибо конкуренция выше.
Ну и ещё я прям ощутил флешбек себя год назад. Тоже ушел из корпорации, работал в более мелкой чем Авито конторе. А потом начал просто общаться (когда нет страха, ты доволен жизнью, можно просто гнуть свою линию на НН). Сами подумайте как часто отказывают вам и как часто отказываете вы и поймёте, что счёт не в вашу пользу. И вот я начал выбирать медленно. Если проект не нравился я просто не шел на второй собес, в том числе и в кампании о которых все грезят, ибо там есть болота. И потом пришло предложение, от которого нельзя было отказаться(чисто случайно от корпорации, это мог быть и стартап) и вот оно - ДМС, эксперименты, только новые технологии и прочие плюшки.
По статье видно, что скорее всего она написана под воздействием внешней мотивации. Сильно много акцента не на личности автора, а на месте где он работает. Скорее всего было менторство или иная форма содействия со стороны кампании. Авторы пишущие от себя все таки больше уделяют внимание себе. А значит Авито не сильно отличается от Корпораций.
Эксперименты. Корпорации проводят эксперименты на уровне целых проектов, а не на уровне отдельного микросервиса или технологии. В этом их сила для сильных разработчиков. Можно испытать свои силы на масштабных проектах с нуля. Увы Авито себе такое позволить не может. Потому тут дело не в корпорации или не корпорации, а просто в стечении обстоятельств. Автор просто не нашла такого проекта с нуля, где можно раскрыть себя. Но зато нашла себя на новом рабочем месте. Это тоже хорошо, поздравляю.
Но в целом статья выглядит как просто PR-проект Авито.
А вообще автору совет. Я тоже долго борол выгорание и пытался найти где бы дать волю духу авантюризма и тяге к экспериментам. В итоге просто пошел в проект с нуля в Корпорацию ))) И это просто кайф на самом деле. Не важно где ты работаешь. Проект с нуля хорош везде. Мне кажется в целом любому человеку кто дошел до Senior/Teach Lead надо идти делать с нуля.
На самом деле проблема разделения баз на 'холодные' и 'горячие' данные актуальна до сих пор. Я в своей практике сталкивался со многими системами, долго работал в чистом дата-инжиниринге. И что странно, люди вообще как будто не видят проблемы хранить данные вместе.
Всего в одном месте я увидел полноценное разделение на DWH и OLTP. Причем со связью многие ко многим. Т.е абсолютно масштабируемая, можно сказать микросервисная архитектура БД, где каждый DWH или OLTP сегменты выполняют свою узкую задачу.
Тема действительно слабо освещена, но она актуальна всегда и везде. Делить на холодные и горячие данные надо. А если ещё и бить по сервисам - то проблем масштабирования данных не будет также как и проблем масштабирования микросервисных приложений с такими же плюсами и минусами.
Просто средства другие. А-ля Airflow вместо Kafka.
Ещё можно сказать, что grpc хорош для случаев взаимодействия 1 к 1. А брокеры вроде Кафки и реббита для бродкастинга. Часто возникают задачи обработки одного события в множестве сервисов - пилить grpc в каждом - ад. Но как взаимодействие 1 к 1 grpc просто бескомпромиссный вариант.
Мне кажется запускать сервис в массы до того как решение будет завернуто в абстракцию вокруг результирующего алгоритма - как минимум глупо.
Прочитал задачу. Понял алгоритм.... И какая то куча закомментированного кода в решении. Вы это видели где то? Я нет. Все сервисы требуют только написание алгоритма. А тут.... Ну как есть тут в общем. Пока не хочется решать тут задачки.
Видимо в яндекс хорошо умеют решать алгоритмические задачи, но не очень дружат с абстракциями :)
Около века назад все человечество было в панике. Рабочих лешали хлеба машины. И чем дальше шел прогресс тем больше людей оставалось без работы. Однако никто не зрит в корень. Без работы оставались те, кто не захотел дружиться с машинами - они уходили в сторону. Без хорошей работы оставались те, кто просто изучал как машины работают и становились мало оплачиваемыми операторами.
Однако остались на коне те, кто сохранили навыки обслуживания машин. Кто понимал как машина работает. Кто мог в любой момент починить машину. Кто мог заменить машину в критической ситуации. Такие люди стали получать в 2-3 раза больше чем получали. Так как работодатель лучше заплатит им чем откажется от машин.
И даже сейчас на любом заводе есть главный инженер и пара его помощников с ЗП много выше чем у простого трудяги. Так как это повелители машин. Они не только знают что машина делает, но могут рассказать до шестерёнки как она это делает. А также устранить любой сбой в технологическом процессе
Теперь смотрите. АИ пишет код и есть только моделеры и менеджмент. И вдруг код начинает работать не так как надо. Кто решит проблему? Моделер? Менеджер? Аналитик? Да черт то там. Только программер. Человек кто кодил руками. Только он способен будет управлять хаосом. Да, от этого человека будет требоваться понимание работы ИИ. Это должен быть крутой программист. Но и получать он будет больше чем сейчас в разы. Так что программисты будут нужны и через 100 лет. Но не в таком количестве. И зарабатывать такие будут больше.
Те кто не захотят дружиться с ИИ уйдут из ИТ. Те кто научатся только декларировать ИИ - будут операторами на малой ставке. А вот те кто будут в состоянии заменить ИИ в критической ситуации и понять что там ИИ нагородил - это будут те, кто соберёт сливки в новой ИИ революции.
Я думаю все понимают каким станет размер глаз просто аналитика или менеджера, когда в один момент система начнет работать не так как нужно, а рядом нет того кто умеет читать и понимать код
Откуда вообще плюс рейтинг у подобной статьи на Хабре?
Я вот хочу ответить всем HR. Сейчас в России инфляция 10-20 процентов. Поэтому зп должна подниматься независимо от ИПР на эту цифру. Иначе через 2 года новички без опыта в фирме будут получать больше чем я.
Далее. Если просите ИПР. Должен быть четкий процент повышения ЗП плюсом к инфляции. Т.е есть ИПР, есть рост к ЗП +20-30 процентов.
А стойте. ИПР же не для работника. Он для экономии фота. Что я тут фигню пишу. ИПР создан, чтобы работодатель мог оправдать НЕ ПОВЫШЕНИЕ зп. Поэтому фирмы с ИПР - мимо. Это в наши дни крест. А те кто продвигают ИПР застряли в бюрократии.
В нормальных фирмах, ИПР - удел тимлидов. А задача НР найти хороших лидов и не мучать сотрудников бесполезным бумагомарательством. Так как по сути вы давно уже превратили ИПР в реализацию своего ИПР. Именно так. Мне надо что то сделать, но я не в состоянии придумать реально крутую новую фичу по развитию сотрудников.... Я введу ИПР. Смешно.
Умный человек должен понять одну истину. Оценкой развити личности не может заниматься человек, некомпетентный в области, которую он оценивает. А у нас именно так и есть. НР бежит и насилует мозг техдиру, чтобы тот выдал Критерии Роста. Техдир плевал на это и быстро делает план, в котором лажа. НР выдает его за свое ноухау и далее начинает мучать мозг рядовому прогеру.
Но в нормально построенной эффективной моделе управления мотивацией сотрудников должен заниматься только лид и никто более. Все общение с сотрудниками только через Лида. Вообще убрать любые связи НР сотрудник после найма. Это лишнее.
На самом деле если вы сделали хобби работой, и это привело к указанным автором проблемам, то вы просто ошиблись и работа не совпала с вашим хобби. Вам просто показалось. Либо показалось что вы любите свое хобби, либо показалось, что работа на 100% соответствует этому хобби.
Ведь в работе есть ещё ответственность, если ваше хобби не подразумевает ответственный подход, понятно что вы разочаруетесь в работе.
В работе есть ещё и выполнение не своих надуманных задач, а выполнение реальных задач. Если вы не склонны к аналитике, системному мышлению и вам не нравится процесс формализации и декомпозиции чужих хотелок - вы тоже устанете. Так как все это не было частью вашего хобби.
Ведь что происходит. Когда вы бегаете для хобби и у вас вдруг заболел бок, вы идете домой, закончив пробежку. В какой то момент, посчитав себя реально крутым вы идете на городские соревнования по бегу. Полумарафон. И где то к середине этого мероприятия, вы можете возненавидеть бег и свое хобби. А причина проста - переоценка своих сил. И не более. Значит воля к победе не является вашим хобби. Вы не получаете удовольствия от соперничества. Вам нравится только бег и соревнования просто не для вас.
Поэтому скажем так, вы выгорите, если переоценили масштаб своего хобби. Безответственное хобби с решением своих задач и взятие на себя ответственности за решение чужих задач - это две разные вещи.
Сам в свое время переквалифицировался на более интересный стек, который был моим хобби. Вообще ничего из указанного не подходит. Выгорания ноль, усталости ноль. Иногда даже жду понедельника.
Бывают конечно моменты, когда хочется поубивать всех вокруг и себя в том числе за то, что сел за баранку этого драндулета. Но проходит день, задача решается и ты опять полон сил.
Я соглашусь с вашим утверждением, если вы приведете пример расширения структуры методом вашего целевого интерфейса с условием, что структура хранится в чужом пакете, который вы не имеете технической возможности расширять.
Допустим есть структура ForeignLogger с методом LogItBro()
У вас есть в коде ваша структура MyLogger с методом LogItSister()
Вам нужно позвать метод LogItSister(), который реализует функциональность LogItBro() без расширения структуры ForeignLogger.
Т.е конструкция func (f *ForeignLogger) LogItSister() запрещена правилами Go. Компилятор выдаст ошибку на такой код.
Именно в этом суть адаптера. А не в абстракции структур, который вам принадлежат и вы их разрабатываете.
Ну не совсем. Если есть какой то пакет со схожей функциональностью. Не важно какой. И его нужно прикрутить к уже работающей системе. Но сигнатуры методов разные, а значит и интерфейсы разные.
Какой бы утиной ни была типизация, вы не сможете только интерфейсами обойтись. В исходный пакет целевой библиотеки вы не залезете, она не ваша. И не добавите там вашу сигнатуру. В своем пакете вы также не прицепите нужную сигнатуру на чужой объект, вас компилятор отправит куда подальше.
Так что я бы не сказал, что интерфейсы ГО прям так сразу реализуют данный паттерн.
Без него в ГО можно обойтись запросто, когда пишешь и проектируешь с нуля. И я бы даже сказал, если у вас свежая система с адаптером на свои же библиотеки, значит что-то пошло не так :) И пора искать того, кто развел хаос в сигнатурах на уровне абстракций однотипных структур.
А вот в кейсах со старым кодом и чужими библиотеками. Иногда может потребоваться
Ну может я резко выразился. Скажем так, наличие Wife является одним из важных факторов, которые определят мощь адаптера - его возможность прикрутиться к уже имеющемуся функционалу.
С горяча в общем :)
Я подправлю статью, чтобы не было разночтений. Спасибо
Суть в том. Что переключение партиций позволяет делать все на горячую. И не нужно прыгать со вью поверх таблиц и ждать ночи. Все можно делать днём. В отличие от Delete+Insert.
Но саму идею двух таблиц view_total = main + inc и мы применяем на практике. Но после проверок горячего наката, поняли, что для exchange все можно делать на горячую. DBA не прибегали/пользователи таблиц проблем не выявили. Нагрузочные тесты также не расходились и не убивали базу.
Что то 4 пункта преимуществ не имеют ни одного технического реально важного аспекта )))) главное что должна делать модель - писать код. Если она не может этого делать, а гига код не может даже близко, не важно какой язык она понимает и с каким Легаси работает
Тест на нахождение 10 непохожих существительных доказывает не креативность, а умение моделей решать стандартные задачи по семантическому анализу больших текстов. Так что слово креативность тут чисто для Хайпа.
И как блин у людей поворачивается палец поставить ChatGPT рядом с YandexGPT/GigaChat, который сыпется на любой реальной алгоритмической задаче, где добавлено дополнительное условие.
И почему тут нет Qwen, который на программировании себя реально лучше показывает. Я лично уже давно понял, что он лучше.
В работе используем ChatGPT. Ржом дружно даже с него, когда надо сделать, что-то кроме тупой алгоритмики или отрисовки гуев. Дома для себя Qwen. Yandex и Giga вообще думать не умеют. Чисто поисковики с эмууляцией контекста.
Удачи тем кто верит, что нейросети проживут без присмотра десятка матёрых спецов в своей области ) В бизнес логике так и подавно нейронки загонят в мир иллюзий своего владельца. А потом придется разгребать
Картинки, видосики, диспетчера и первая линия поддержки, консультант по архитектуре кода. Вот реальный предел текущих моделей.
Чтобы через год заявить, что если компания хочет сохранить все свои ИТ преференции все сотрудники должны быть сертифицированы. И начать рубить бабло из воздуха
Последние три года они как с цепи сорвались. Давайте без разбора лочить иностранных конкурентов - пофиг на то что бизнес страдает. Теперь будем паковать воздух (тесты) в банки и продавать его (требование закона на прохождение тестов)
Странно. Вроде первое апреля два месяца назад прошло.
Если по пунктам разложить все плюсы и минусы приведенные в статье. То побороть минусы корпорации проще чем минусы мелких кампаний. Работал и там и там и вернулся в Корпорацию. Почему?
Корпорации часто запускают мощные инфраструктурные проекты и так как культура ВСЕХ гигантов крайне высока, то новые проекты всегда запускаются на самом высшем уровне - кубер в клауде и иже с ними. Более того, тебя ещё будут мониторить и прессовать, что ты лисапэды изобретатешь. Так как все эти центры компетенции, над которыми многие смеются - они работают и там сидят реальные мозги, а не бюрократы. А ругают такие центры только вечные джуны/мидлы.
Итого. Хотим экспериментов, реализации идей и атмосферы ИТ - идем в молодой проект корпорации и бреем НН, которые зовут в старые проекты на Легаси. Главное уметь отказывать даже на самые вкусные проекты. Ибо даже в Яндексе есть всякие болота вроде HR-Tech (в народе HR течь).
Но готовимся к перссу высшего уровня, так как будут требовать подхода современного. Полного покрытия тестами, мокирования, контейнеризации и т.п (привожу просто так набор терминов, которые критически важны в современном мире, но увы не все понимают суть их), конкретика в виде технологий не так важна - они у всех разные. Причем без компромиссов. MVP не прокатит.
ПЫСЫ. Почему ответил - отвечаю редко. Не люблю категоричность и путаницу в причино следственных связях. В корпорациях тоже можно побороть все минусы и остаться только с плюсами, просто надо показать что ты можешь. Там отбор выше ибо конкуренция выше.
Ну и ещё я прям ощутил флешбек себя год назад. Тоже ушел из корпорации, работал в более мелкой чем Авито конторе. А потом начал просто общаться (когда нет страха, ты доволен жизнью, можно просто гнуть свою линию на НН). Сами подумайте как часто отказывают вам и как часто отказываете вы и поймёте, что счёт не в вашу пользу. И вот я начал выбирать медленно. Если проект не нравился я просто не шел на второй собес, в том числе и в кампании о которых все грезят, ибо там есть болота. И потом пришло предложение, от которого нельзя было отказаться(чисто случайно от корпорации, это мог быть и стартап) и вот оно - ДМС, эксперименты, только новые технологии и прочие плюшки.
По статье видно, что скорее всего она написана под воздействием внешней мотивации. Сильно много акцента не на личности автора, а на месте где он работает. Скорее всего было менторство или иная форма содействия со стороны кампании. Авторы пишущие от себя все таки больше уделяют внимание себе. А значит Авито не сильно отличается от Корпораций.
Эксперименты. Корпорации проводят эксперименты на уровне целых проектов, а не на уровне отдельного микросервиса или технологии. В этом их сила для сильных разработчиков. Можно испытать свои силы на масштабных проектах с нуля. Увы Авито себе такое позволить не может. Потому тут дело не в корпорации или не корпорации, а просто в стечении обстоятельств. Автор просто не нашла такого проекта с нуля, где можно раскрыть себя. Но зато нашла себя на новом рабочем месте. Это тоже хорошо, поздравляю.
Но в целом статья выглядит как просто PR-проект Авито.
А вообще автору совет. Я тоже долго борол выгорание и пытался найти где бы дать волю духу авантюризма и тяге к экспериментам. В итоге просто пошел в проект с нуля в Корпорацию ))) И это просто кайф на самом деле. Не важно где ты работаешь. Проект с нуля хорош везде. Мне кажется в целом любому человеку кто дошел до Senior/Teach Lead надо идти делать с нуля.
На самом деле проблема разделения баз на 'холодные' и 'горячие' данные актуальна до сих пор. Я в своей практике сталкивался со многими системами, долго работал в чистом дата-инжиниринге. И что странно, люди вообще как будто не видят проблемы хранить данные вместе.
Всего в одном месте я увидел полноценное разделение на DWH и OLTP. Причем со связью многие ко многим. Т.е абсолютно масштабируемая, можно сказать микросервисная архитектура БД, где каждый DWH или OLTP сегменты выполняют свою узкую задачу.
Тема действительно слабо освещена, но она актуальна всегда и везде. Делить на холодные и горячие данные надо. А если ещё и бить по сервисам - то проблем масштабирования данных не будет также как и проблем масштабирования микросервисных приложений с такими же плюсами и минусами.
Просто средства другие. А-ля Airflow вместо Kafka.
Ещё можно сказать, что grpc хорош для случаев взаимодействия 1 к 1. А брокеры вроде Кафки и реббита для бродкастинга. Часто возникают задачи обработки одного события в множестве сервисов - пилить grpc в каждом - ад. Но как взаимодействие 1 к 1 grpc просто бескомпромиссный вариант.
Мне кажется запускать сервис в массы до того как решение будет завернуто в абстракцию вокруг результирующего алгоритма - как минимум глупо.
Прочитал задачу. Понял алгоритм.... И какая то куча закомментированного кода в решении. Вы это видели где то? Я нет. Все сервисы требуют только написание алгоритма. А тут.... Ну как есть тут в общем. Пока не хочется решать тут задачки.
Видимо в яндекс хорошо умеют решать алгоритмические задачи, но не очень дружат с абстракциями :)
Около века назад все человечество было в панике. Рабочих лешали хлеба машины. И чем дальше шел прогресс тем больше людей оставалось без работы. Однако никто не зрит в корень. Без работы оставались те, кто не захотел дружиться с машинами - они уходили в сторону. Без хорошей работы оставались те, кто просто изучал как машины работают и становились мало оплачиваемыми операторами.
Однако остались на коне те, кто сохранили навыки обслуживания машин. Кто понимал как машина работает. Кто мог в любой момент починить машину. Кто мог заменить машину в критической ситуации. Такие люди стали получать в 2-3 раза больше чем получали. Так как работодатель лучше заплатит им чем откажется от машин.
И даже сейчас на любом заводе есть главный инженер и пара его помощников с ЗП много выше чем у простого трудяги. Так как это повелители машин. Они не только знают что машина делает, но могут рассказать до шестерёнки как она это делает. А также устранить любой сбой в технологическом процессе
Теперь смотрите. АИ пишет код и есть только моделеры и менеджмент. И вдруг код начинает работать не так как надо. Кто решит проблему? Моделер? Менеджер? Аналитик? Да черт то там. Только программер. Человек кто кодил руками. Только он способен будет управлять хаосом. Да, от этого человека будет требоваться понимание работы ИИ. Это должен быть крутой программист. Но и получать он будет больше чем сейчас в разы. Так что программисты будут нужны и через 100 лет. Но не в таком количестве. И зарабатывать такие будут больше.
Те кто не захотят дружиться с ИИ уйдут из ИТ. Те кто научатся только декларировать ИИ - будут операторами на малой ставке. А вот те кто будут в состоянии заменить ИИ в критической ситуации и понять что там ИИ нагородил - это будут те, кто соберёт сливки в новой ИИ революции.
Я думаю все понимают каким станет размер глаз просто аналитика или менеджера, когда в один момент система начнет работать не так как нужно, а рядом нет того кто умеет читать и понимать код
Откуда вообще плюс рейтинг у подобной статьи на Хабре?
Я вот хочу ответить всем HR. Сейчас в России инфляция 10-20 процентов. Поэтому зп должна подниматься независимо от ИПР на эту цифру. Иначе через 2 года новички без опыта в фирме будут получать больше чем я.
Далее. Если просите ИПР. Должен быть четкий процент повышения ЗП плюсом к инфляции. Т.е есть ИПР, есть рост к ЗП +20-30 процентов.
А стойте. ИПР же не для работника. Он для экономии фота. Что я тут фигню пишу. ИПР создан, чтобы работодатель мог оправдать НЕ ПОВЫШЕНИЕ зп. Поэтому фирмы с ИПР - мимо. Это в наши дни крест. А те кто продвигают ИПР застряли в бюрократии.
В нормальных фирмах, ИПР - удел тимлидов. А задача НР найти хороших лидов и не мучать сотрудников бесполезным бумагомарательством. Так как по сути вы давно уже превратили ИПР в реализацию своего ИПР. Именно так. Мне надо что то сделать, но я не в состоянии придумать реально крутую новую фичу по развитию сотрудников.... Я введу ИПР. Смешно.
Умный человек должен понять одну истину. Оценкой развити личности не может заниматься человек, некомпетентный в области, которую он оценивает. А у нас именно так и есть. НР бежит и насилует мозг техдиру, чтобы тот выдал Критерии Роста. Техдир плевал на это и быстро делает план, в котором лажа. НР выдает его за свое ноухау и далее начинает мучать мозг рядовому прогеру.
Но в нормально построенной эффективной моделе управления мотивацией сотрудников должен заниматься только лид и никто более. Все общение с сотрудниками только через Лида. Вообще убрать любые связи НР сотрудник после найма. Это лишнее.
На самом деле если вы сделали хобби работой, и это привело к указанным автором проблемам, то вы просто ошиблись и работа не совпала с вашим хобби. Вам просто показалось. Либо показалось что вы любите свое хобби, либо показалось, что работа на 100% соответствует этому хобби.
Ведь в работе есть ещё ответственность, если ваше хобби не подразумевает ответственный подход, понятно что вы разочаруетесь в работе.
В работе есть ещё и выполнение не своих надуманных задач, а выполнение реальных задач. Если вы не склонны к аналитике, системному мышлению и вам не нравится процесс формализации и декомпозиции чужих хотелок - вы тоже устанете. Так как все это не было частью вашего хобби.
Ведь что происходит. Когда вы бегаете для хобби и у вас вдруг заболел бок, вы идете домой, закончив пробежку. В какой то момент, посчитав себя реально крутым вы идете на городские соревнования по бегу. Полумарафон. И где то к середине этого мероприятия, вы можете возненавидеть бег и свое хобби. А причина проста - переоценка своих сил. И не более. Значит воля к победе не является вашим хобби. Вы не получаете удовольствия от соперничества. Вам нравится только бег и соревнования просто не для вас.
Поэтому скажем так, вы выгорите, если переоценили масштаб своего хобби. Безответственное хобби с решением своих задач и взятие на себя ответственности за решение чужих задач - это две разные вещи.
Сам в свое время переквалифицировался на более интересный стек, который был моим хобби. Вообще ничего из указанного не подходит. Выгорания ноль, усталости ноль. Иногда даже жду понедельника.
Бывают конечно моменты, когда хочется поубивать всех вокруг и себя в том числе за то, что сел за баранку этого драндулета. Но проходит день, задача решается и ты опять полон сил.
Я соглашусь с вашим утверждением, если вы приведете пример расширения структуры методом вашего целевого интерфейса с условием, что структура хранится в чужом пакете, который вы не имеете технической возможности расширять.
Допустим есть структура ForeignLogger с методом LogItBro()
У вас есть в коде ваша структура MyLogger с методом LogItSister()
Вам нужно позвать метод LogItSister(), который реализует функциональность LogItBro() без расширения структуры ForeignLogger.
Т.е конструкция func (f *ForeignLogger) LogItSister() запрещена правилами Go. Компилятор выдаст ошибку на такой код.
Именно в этом суть адаптера. А не в абстракции структур, который вам принадлежат и вы их разрабатываете.
Можно псевдокодом
Ну не совсем. Если есть какой то пакет со схожей функциональностью. Не важно какой. И его нужно прикрутить к уже работающей системе. Но сигнатуры методов разные, а значит и интерфейсы разные.
Какой бы утиной ни была типизация, вы не сможете только интерфейсами обойтись. В исходный пакет целевой библиотеки вы не залезете, она не ваша. И не добавите там вашу сигнатуру. В своем пакете вы также не прицепите нужную сигнатуру на чужой объект, вас компилятор отправит куда подальше.
Так что я бы не сказал, что интерфейсы ГО прям так сразу реализуют данный паттерн.
Без него в ГО можно обойтись запросто, когда пишешь и проектируешь с нуля. И я бы даже сказал, если у вас свежая система с адаптером на свои же библиотеки, значит что-то пошло не так :) И пора искать того, кто развел хаос в сигнатурах на уровне абстракций однотипных структур.
А вот в кейсах со старым кодом и чужими библиотеками. Иногда может потребоваться
Про логгер написал.
Я учту пожелание. Добавлю практический пример.
Ну может я резко выразился. Скажем так, наличие Wife является одним из важных факторов, которые определят мощь адаптера - его возможность прикрутиться к уже имеющемуся функционалу.
С горяча в общем :)
Я подправлю статью, чтобы не было разночтений. Спасибо
Суть в том. Что переключение партиций позволяет делать все на горячую. И не нужно прыгать со вью поверх таблиц и ждать ночи. Все можно делать днём. В отличие от Delete+Insert.
Но саму идею двух таблиц view_total = main + inc и мы применяем на практике. Но после проверок горячего наката, поняли, что для exchange все можно делать на горячую. DBA не прибегали/пользователи таблиц проблем не выявили. Нагрузочные тесты также не расходились и не убивали базу.
Спасибо. Учел замечания.