Saboteur

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

Ну это ваши личные проблемы. Работа это не школа не институт и не курсы. На работе заказчик платит за то, что хочет заказчик, а не за то, что хочет разработчик.

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

Этот вопрос совершенно не нужен в интернет. Спрашивай своего тимлида. Не во всех проектах есть "нормальные задачи", как ты их считаешь. Где-то ведь продукт уже написан, им пользуются люди, и в нем не нужно ничего дорабатывать. Просто обслуживать - решать проблемы эксплуатации, возможно подправлять баги, возможно обновлять что-то, чтобы продукт запускался на более новой версии java или оборудовании.
И это НОРМАЛЬНО. С точки зрения пользователя, тебе было бы интересно купить машину, а потом платить каждый месяц еще 10% ее стоимости за то, что в ней каждый месяц то форма дверей меняется то диаметр колес то еще что-то? Думаю нет, ты бы хотел купить машину один раз и не лазить под капот несколько лет.

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

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

Ну а в целом - да, есть проекты, где больше разработки с нуля, есть проекты, где много миграций и рефакторинга, есть где больше просто поддержки. И специалисты везде нужны.

Странный вопрос.
На собеседовании все уместно. Ты же не забывай, что собеседование это не ЕГЕ.
Это диалог двух сторон. Если кандидату не понравился вопрос, он может встать и уйти.
Если он не знает ответ, он может что-то насочинять, и если ты грамотный специалист ты увидишь что он тут отгадывает или точно знает.

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

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

Если будешь читать много книжек - научишься читать книжки.
Если будешь писать код - научишься писать код.

Не нужно поперечитывать книжки и только потом начинать что-то писать.
Не нужно прочитать ЦЕЛУЮ (на самом деле всего лишь одну) книжку и сразу писать свою большую 2д игру.
Напиши сперва простую программку. Простой калькулятор. Простое окошко с кнопкой. Если 2д игру, то крестики нолики или морской бой - тебе нужно освоить базовые вещи, чтобы не было простых вопросов. Потом усложняй.

А цела куча ошибок? Я просидел 2 дня над 5 минутной задачей? Ошибка 1 надо было понимать в начале что это " a" а не "a", пазлы ошибки и т.д

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

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

Каждому человеку проще так, как он привык. Совершенно точно, что не обязательно тупо читать книгу. Нужно искать свои методы. Ибо нет лучшей книги и нет лучшего метода. Есть тот, который подходит конкретно тебе. И нужно также понимать что самый подходящий для тебя метод сейчас работает, а через месяц нет, или одна тема зайдет так, другая через практику, третья через видяшку. Ну или можно все одним способом, но затратив разное количество усилий.

, а это нормально что прочитав книгу ты вот захотел что то написать, перед этим посмотреть и проанализировать как кто то написал что то похожее

Ну а почему бы нет? Все упирается исключительно во время. У кого есть возможность анализировать, у кого нет. Анализировать как это написали другие полезно. Прикол в том, что "посмотреть" чужой код - это не полистать. Это нужно сесть и долго разбираться, пока вникнешь в логику чужого кода. Быстро подсмотреть можно какую-то совсем мелочь.

А вот теперь другая ситуация. Вас привели на завод и прикрепиле к мастеру, вам не стали показывать ВСЕ инструменты и объяснять как они работают, а МАСТЕР стал делать КАРКАС для двигателя (ну то на что все крепиться будет) и попутно ПО шагово объясняя ход своих мыслей

Вот на базе вашего примера поясню суть.
Двигатель, а точнее современный двигатель, это такая деталь, которую создавали много людей на протяжении поколений. И пока вам МАСТЕР пояснит ход всех своих мыслей, у вас уйдет жизнь.
И основная проблема, что вы предыдущую мою фразу может и прочитали, но не осознали. Жизнь человека - действительно ОЧЕНЬ короткая. И если 20 летнему студенту может показаться, что 40 лет это уже старик, можно умножить 20 на два и внезапно осознать что молодой 20-летний студент уже половину своей жизни прожил.

Поэтому иногда стоит сразу показать все существующие инструменты ВКРАТЦЕ, чтобы человек знал что уже было изобретено и можно взять готовым, а потом уже давать задачи, чтобы пользуясь готовыми инструментами новичок создавал программу, а не изобретал с нуля колесо, молоток, увеличительное стекло и так далее.

Учись задавать правильные вопросы. Это когда ты знаешь примерно половину ответа. В ИТ начало пути это не тогда, когда ты выбираешь книгу почитать. А когда ты уже написал свою первую сложную программу, и после этого, читая ОЧЕРЕДНУЮ книжку думаешь что ее можно было написать гораздо лучше и гораздо проще.

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

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

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

Но это все довольно условно, так как сейчас виртуализация достигла платформ, и если 30 лет назад под платформой подразумевался процессор, то сейчас платформой может быть даже браузер (для webassembly, css и js) и так далее.

P.S. И да, ассемблер - это текст. А конечный результат, например для С++ это исполняемый файл с машинным кодом и структурой исполняемого файла, в котором заложено как и что загрузить в память и куда передать управление.

Вы немного путаете массив массивов и многомерные массивы.

А массив массивов, это когда значение конкретного элемента это тоже целый массив. И в этом случае обратиться к нему проблематично. Но можно через ссылку - сперва извлекаем ссылку потом обращаемся к вложенному массиву.

А просто многомерные массивы в перл естественно есть.
Двумерные массивы это просто массив, в котором для обращения к элементу нужно указать два индекса - array(x,y).
Или вот трехмерный массив с тремя индексами array(x,y,z)

почитайте про sed, как раз под вашу ситуацию

sed -n '/19:00,/21:00/{/11.11.11.11\/111/p}' file.log > newfile.log

Все адекватные работодатели:

1. Задают вопрос "когда вы готовы приступить к обязанностям", и 2 недели по КЗОТ это вообще минимальный стандарт. А так могут и месяц подождать, вполне адекватно отнесясь к тому, что после увольнения вы хотите взять небольшой отпуск, например. Но это вполне обговариваемо с работодателем.

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

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

4. Многие ходят на собеседование даже не предполагая менять работу. Кто-то из спортивного интереса, кто-то на всякий случай посмотреть, а вдруг предложат работу мечты. В таких случаях всегда бывает, что сотрудника нужно ждать и месяц и два. Но такие варианты, конечно, встречаются в основном на уровне mid/senior и выше.

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

Там вроде есть консольная утилита sacctmgr, которой можно и задать и посмотреть лимиты ресурсов, но не знаю может ли это сделать обычный юзер

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

p.s. Тут вряд ли нужен тег bash, скорее Linux

Получаем примерную дату за последние сутки с нужной точностью
olddate=$(date -d "-24 hours" "+%d/%b/%Y:%H:%M:%S")
Но тут есть проблема. Если в данную секунду в прошлом не было ни одной записи, мы пролетим мимо. Поэтому округлим хотя бы до часа, но все равно остается риск, если приложение было выключено целый час, то мы не найдем начальную позицию вообще. Как эту проблему решать я не знаю, зависит от того что у вас в файле всегда будет что-то или не всегда и если не всегда, тогда все усложняется. Но давайте пойдем от простого, просто округлить хотя бы до часа:
olddate=$(date -d "-24 hours" "+%d/%b/%Y:%H")

Потом через sed можно найти текст от указанной даты и до конца файла, и тут же фильтруем router:
sed -nE "/$olddate/,\${/router/p}" file.log|wc -l

Ну или однострочник

sed -nE "/$(date -d "-24 hours" "+%d/%b/%Y:%H")/,\${/router/p}" file.log|wc -l

Да любой гит клиент это умеет.
Например в консоли

git ls-files

Ну и любой gui клиент для git должен это уметь.