Wan-Derer

Если я правильно понял задачу, то можно дождаться появления дерева и элементов нужных вам. Но придется всегда знать класс (и под каким он индексом) или id или data. Дальше берем этот элемент, проверяем есть ли он, после того как находим берем данные из всех дочерних узлов.
Можете вставить этот код в консоль в браузере чтобы проверить.

const arr = document.getElementsByClassName('seller-details__parameter');
(function traverse(node = arr[0]) {
  // Проверяем тип узла, чтобы получить только текстовые узлы
  if (node.nodeType === Node.TEXT_NODE && node.textContent.trim() !== '') {
    console.log(node.textContent);
  }
  // Рекурсивно обходим все дочерние узлы
  node.childNodes.forEach(traverse);
})();

Если сервис не обновляется, ему не нужно поднимать версию

В целом версии ведутся по semver, через теги

Из опыта, было два пересмотра зп в рамках одной компании.
1) я точно был уверен, что сто́ю 100$. Получал 65$. Но тоже не хотел заниматься офферами и т.д. Пошел к начальству. Было много разговоров, что ситуация тяжёлая, всем тяжело, там сокращения везде. Подняли до 87$. Спустя неделю я на изи получил оффер на 105$. Для самоутверждения, с компании не увольнялся.

2) спустя 8 месяцев с предыдущего повышения до 87$. Уже на стопроцентов уверен, что сто́ю 160$. Выводы с прошлого раза сделаны. С лёгкостью беру оффер на 160$. Иду к начальству. Диалог продлился 2минуты. Без проблем дали 155$(я сказал, что не интересно менять компанию и готов двинуться).

Да, как крыса, но это рынок и все торгуются. До сих пор работаю в этой же компании и уходить не собираюсь. Следующий пересмотр тоже через оффер, это стопроцентов. И кстати уходить тоже не буду(где-то статистика рекрутеров сломалась)

П.с. суммы указаны чтобы показать процентное соотношение. Это моя история и мои выводы, просто поделился, ни к чему не призываю )

Как показывает мой весьма немалый опыт - даже самое лучшее начальство само не повышает зарплаты. Если между Вами и ЛПР есть еще кто-то промежуточный, поговорите с ним - пусть поговорит с ЛПР. Нехитрый психологический трюк - говорить о зарплате подчиненного всегда проще, чем о своей и говорить с человеком, который не принимает решения тоже проще.

Ну и разумеется, если Вы считаете, что Ваши скиллы выросли - сходите на пару собесов по интересующим вакансиям, чтобы получить подтверждение (или опровержение) этого.

Как грамотно завести разговор с начальником о повышении зарплаты и какими фактами оперировать?

Подходишь с максимально серьёзным лицом и предлагаешь повысить себе зарплату, опираясь на то, как ты развился за этот год и как изменилась твоя рыночная стоимость.

За год успел набить опыт и скилл, влиться в проект и деятельность компании, стал полностью самостоятелен, так как приставленный к моему проекту PM уже почти не участвует в моём проекте, а занимается сторонними с большей командой. Но с момента трудоустройства вопрос о повышении зарплаты не поднимался ни с моей стороны, ни со стороны начальства.

В идеале - сходить на собес в ещё пару каких-нибудь компаний и получить там оффер - тогда при переговорах у тебя на руках уже будет подтверждение твоих слов и запасной план, если зп всё ещё захочется выше, но на текущем месте её не захотят повышать.

Помни, что никаких негативных последствий у тебя не может быть в результате, тк ничего плохого ты и не делаешь.

В первую очередь, тебе нужно дать начальству понять, за что тебе нужно платить больше. Если твоя продуктивность или роль в компании расширилась естественным путём, то это хороший аргумент. Если нет, то проси больше обязанностей и бери больше ответственности.

Нельзя блефовать, ты должен быть понастоящему готовым уйти если условия тебе не подходят. Оффер от другой компании будет твоим козырем в переговорах и планом Б на случай, если всё пройдёт совсем не так.

В долгосрочной перспективе, лучше не выпрашивать прибавку к зп, а менять компанию. Вот так уверенно и без лишних соплей. Так темп карьерного роста будет намного выше, чем если ты 5+ лет будешь работать в одной компании на той же самой должности, даже с ежегодными прибавками.

Вообще, вполне можно прямо вот так всё и рассказать начальству, как вы здесь написали.
1. На настоящий момент я закрываю почти все таски на .Net
2. Приставленный к моему проекту PM уже почти не участвует в моём проекте, я справляюсь сам.
3. С момента трудоустройства вопрос о повышении зарплаты не поднимался, кажется пришло время, обычно зарплата пересматривается два раза в год.

Удобный момент любой, вот прямо завтра идите к начальнику и говорите.
Если захотите предварительно получить реальный оффер со стороны, он придаст вам уверенности, и даст последний аргумент, на случай если начальство не захочет повышать зарплату, а так, можете о нем даже не упоминать.

Нет желания блефовать увольнением и жирным оффером из другой компании, так как текущая меня более чем устраивает, да и на данный момент опасно угрожать уходом начальству, так как it пузырь уже сдулся

Ну так а вы не блефуйте, а действительно получите оффер и говорите по существу. Разумеется уважающий себя разработчик не будет махать выдуманным оффером - он реально его получит и будет открыто говорить с текущим работодателем. При этом разумно скинуть какой-то процент от зарплаты в оффере, ну мол "я готов получать тут чуть меньше, т.к. я тоже не хочу менять сейчас работу". Вот и вся история. Либо признайтесь себе, что у вас и так всё неплохо и вам платят подходящие деньги. Перейдите от теории к действию.

Самое важное это повторение уже сделанной работы.
Фреймворки для вас это уже сделанная работа, которую не нужно повторять. Более того, если фреймворк популярный - это качественная работа, с высокой насмотренностью, известными проблемами и тп.
И вот будет ли у вас такое же качество?
Почитайте ещё про фактор автобуса - вас сбил грузовик/автобус, вы погибли. Что делать с вашим наследием, копаться в нём? Делать новое? Кто этим займётся?
Отдельный вопрос что ваши штуки нужно будет другим людям специально изучать, если подключаться к проектам что вы ведёте или вели. И зачем это бизнесу? как найти людей которые знают ваши инструменты ваш подход?
К примеру даже у крупных компаний проблемы с подобным: например движок EA frostbite, который они мучают и при наёме новых людей их нужно прям обучать обучать всем фишкам, костылям и тп. С UE, Unity таких проблем нет.

Так что, если делаете лично для себя, само развитие и тп - это круто и праивльно, делать свои костыли, экспериментировать.
Если вы делаете для кого-то другого - вы подставляете заказчика, подкладываете бомбу под бизнес. Которая может потом сильно затруднить развитие.

Тут вчера женщина спрашивала, что такое библиотеки.
Мой ответ ей, подойдет и вам.
Вы можете собрать лен, спрясть нитки, соткать полотно, скроить и пошить рубаху, это займет у вас месяц.
А клиенту нужна рубаха, поэтому он пойдет к портному, который возьмет отрез ткани и сошьет её за несколько дней.
И даже если клиенту не важны сроки (хотя такого не бывает), кто оплатит вашу возню со льном?

Почему это не имеет ценности?

Для кого? Для вас или для заказчика?

Что нужно работодателю?
Ему нужен код, который будет выполнять его бизнес-задачи.

Как можно написать этот код?
1, Как вы - "я крут, я придумал свой фреймворк"
2, Взять уже готовый slim/laravel/symfony

Какая разница, спросите вы?
Для вас – никакой. ВЫ сделали проект и забыли про него. А Клиент потом захочент внедрить новые возможности.

У него опять будут варианты:

1, Искать вас для доработок, потому что вы делали систему, и хорошо ее знаете (а ваша доступность может быть неприемлема).
2, Нанять любого спеца по slim/laravel/symfony.

И вот тут становится очевидным преимущество использования популярных решений.

В моем случае ошибкой было определение sessionCreationPolicy(SessionCreationPolicy.STATELESS); Я удалила эту строку.
В своей программе я создала свой собственный компонент для перенаправления после успешной аутентификации, но я забыла использовать его в WebSecurityConfig.
Правильный код

@Configuration
@EnableWebSecurity
public class WebSecurityConfig {
@Autowired
Securityhandler successHandler;

@Bean
public UserDetailsService userDetailsService() {
return new UserDetailsServiceImpl();
}

@Bean
public BCryptPasswordEncoder passwordEncoder() {
return new BCryptPasswordEncoder();
}

@Bean
public AuthenticationManager authenticationManager(AuthenticationConfiguration authConfig) throws Exception {
return authConfig.getAuthenticationManager();
}

@Bean
public DaoAuthenticationProvider authenticationProvider() {
DaoAuthenticationProvider authProvider = new DaoAuthenticationProvider();
authProvider.setUserDetailsService(userDetailsService());
authProvider.setPasswordEncoder(passwordEncoder());
return authProvider;
}

@Bean
public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
http.authorizeHttpRequests().requestMatchers("/acthasform/").permitAll().anyRequest().authenticated();
http.authenticationProvider(authenticationProvider());
http.formLogin().loginPage("/login").permitAll().successHandler(successHandler).usernameParameter("username")
.passwordParameter("password").permitAll().and().logout()
.permitAll().and().exceptionHandling().accessDeniedPage("/403");

return http.build();


}
}

@Component
public class Securityhandler implements AuthenticationSuccessHandler{


@Override
public void onAuthenticationSuccess(HttpServletRequest request, HttpServletResponse response,
Authentication authentication) throws IOException {
Set roles = AuthorityUtils.authorityListToSet(authentication.getAuthorities());
if (roles.contains("ROLE_ADMIN")) {
response.sendRedirect("/regulatoryform/");
}
else {
response.sendRedirect("/regulatoryact/");
}
}
}

1 или 2.

Алгоритмы брать не надо. Седжвик вообще писал не про Java а только про алгоритмы.
У него - целое семейство книг такого вида. Сначала Алгоритмы на С. Потом на C++ И потом Java. Он по сути портировал исходники. Какой толк вам в таком портировании?

А Хорстман, Эккель - вполне себе норм.

"Java. Библиотека профессионала", Хорстманн.

Минусы:

1.Буду медленно развиваться как профессионал и поверхностно погружаться в темы.

То есть на новой, сложной работе, где используется множество новых технологий, вы будете развиваться медленнее? Как так?

2.Буду говнокодить, ибо темп работы высокий.

Все говнокодят. Но вас берут как джуна. Код ревью есть в проекте? Опять же, на своих ошибках учатся, чтобы потом выдавать более хороший код.

3.Знакомые опытные ребята говорят, что фулстек джунов не существет и это вообще треш.

Все так, но позиция есть и оффер есть, значит что-то там делать можно.

4.Из-за того, что я не технарь и будет много разных технологий, придется очень много овертаймить ближайший год.

Вы айтишник, но не технарь, это как? Бумажка не делает из человека технаря. Да, иметь документ это прикольно, но человеку не нужен паспорт, чтобы подтвердить, что он человек.

5.Перманентный стресс, от скорости работы с разными технологиями+общение на английском(при учете что никогда не общался на английском). Только читал+видосы смотрел+переписывался.

Прокачать английский очень даже неплохо.
Чтобы не было стресса, занимайся работой в рабочее время. С той скоростью, с которой можешь. Лучше постараться себя организовать в рабочее время, чем овертаймить по ночам. Задачи "это нужно сделать на вчера" следует адекватно оспаривать с руководством, выдавая реалистичные сроки, либо адекватное вознаграждение.

6.Переезд в другой город, + если завалю испыт или сам захочу уйти, надо будет возвращаться в свой город.

Если молод, нет семьи и ребенка, то какие проблемы на три месяца сделать себе эксперимент?

7.Надо уволиться с нынешней работы и в случае, если уволят/уволюсь после испыта, придется искать новую работу

А для чего ты вообще искал новую работу и получал оффер? Хотел работать сразу на двух?

Считай, что тебе сильно повезло. Джуна да ещё и на такой бэкграунд...
Будешь дураком, если откажешься

Судя по обозначенным минусам - вы уже для себя всё решили.

Я бы посоветовал, тк это первый опыт, всётаки сходить на испытательный, а если все беспокойства оправдаются - со спокойной душой уйти

Зарплата - 500 долларов до испыта, 700 - после.

Есть неиллюзорный шанс, что:
1. К долларам это ни разу не привязано
2. После испытательного так и останется 500.

Дело в том, что позвали меня на позицию Full-stack(junior). Если бы это был фулстек веб(нода+реакт), допустим, скорее всего я бы согласился.

Но тут надо разбираться с любыми технологиями, которые нужны заказчику(компания аутсорс). Мне сразу сказали, что надо будет и с мобилками работать и уметь деплоить и с кубернетисом работать.

Всему можно научиться. Уточняй какой стек и думай, хочешь ли ты в этом развиваться.

Так же из-за специфики работы, пм будет общаться с заказчиком, но будут очень частые случаи, когда надо будет созваниваться с заказчикам, уточнять какие-то моменты + презентовать продукт по результатам работы.

Это норма для небольших компаний.

3.Знакомые опытные ребята говорят, что фулстек джунов не существет и это вообще треш.

Фулстек сеньоров тоже)
Если хочешь жёстко по хардам прокачиваться, то надо более узко специализироваться.