Wan-Derer

Вообще, вполне можно прямо вот так всё и рассказать начальству, как вы здесь написали.
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.Знакомые опытные ребята говорят, что фулстек джунов не существет и это вообще треш.

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

через несколько месяцев будет происходить пересмотр квалификации

Спросите у тех кто будет делать пересмотр.

Для повышения внутри аутсорсинговой (не продуктовой) комании на самом деле тебе ни ООП ни PHP не надо.
Надо просто спросить у твоего line-manager или ресурсного-менеджера какой план
твоего роста. И какие вопросы будут звучать на assesment. В обычном ассесменте нет ничего
сложного. Собирается комиссия из 3х и более человек. И с тобой просто беседуют. Узнают
твой опыт. Прошлые проекты. Задают вопросы по уровню квалификации. В составе комисси
обычно есть твой тех-лид. Обычно к ассесменту тебя хорошо знают. И у тебя есть характеристика.

По поводу твоей продуктовой компании. Здесь сложно что либо сказать но ты не должен распыляться
на всякое там ООП и прочее. Это никому не надо. Нужно готовиться только к релевантным вещам
которые есть в компании. Например - компания использует Laravel? Пройди сертификацию.
Это будет более полезный бонус чем безсмысленная философия про эти инкапсуляции и прочее.

Вообще ООП - это страшный моветон и им принято мучать джунов при поступлении.

Плюсую GavriKos -а
Если в компании есть пересмотр, то выяснить процедуры пересмотра. Возможно для пересмотра можно заранее спланировать задачи, при выполнении которых будет пересмотр в сторону повышения.

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

Если же в проекте нет денег для того, чтобы платить своим сотрудникам больше, то вряд ли пересмотр случится, как бы ты не старался (понятно что исключения могут быть, но..)

Думаю, вам будет интересна эта статья, где решается похожая задача:
Yandex Planner. Как планировать вычислительные мощности
И доклад:
Дефрагментация вычислительных ресурсов кластера

Ещё можно посмотреть, как работает шедулер в k8s:
https://habr.com/ru/companies/flant/articles/335552/
https://kubernetes.io/docs/concepts/scheduling-evi...

cmd

for /l %%x in (1, 1, 999999) do echo %%x>>d:\Out.txt