Это, конечно, сильно зависит от того, где вы работаете.
Могу сказать за очень крупные компании, которые делают B2B софт - вы становитесь по настоящему senior'ом в глазах компании, когда вы начинаете меньше думать о своем коде и больше - о гораздо более скучных корпоративных вещах.
Достаточно ли у вас ресурсов, насколько высоко в приоритетах стоит конкретная задача, есть ли другие команды в компании с похожими задачами, есть ли крупные пользователи, которые могут заиметь проблемы от вашей классной новой фичи, как будет устроена миграция на новый фреймворк/бд/протокол/вставить свое.
Были некоторые коллеги, гораздо сильнее меня с точки зрения технической, но могли легко "увлечься" созданием идеальной архитектуры для фич, которые никому были не особо нужны. Код прекрасен, но если никто его не использует - то его для компании, считай, не существует...
Попросту говоря - senior это тот, кто может принимать решения, а это крайне редко сводится к чисто техническим аспектам.
Вариации обобщенных координат и обобщенных скоростей есть независимые вариации
Строго говоря, нет. Если вы варьируете их независимо, т.е. посути варьируете координату и импульс — то это уже не лагранжев формализм, а гамильтонов.
Суть в том, что действие есть функционал от траектории q[t], и варьируете вы только обощенную переменную. Ибо больше нечего варьировать :-)
Мне кажется, вы только сильнее запутаете людей, которые не знают что такое ПНД. Все примеры, кроме первого, мне кажутся крайне неудачными, поскольку сформилированы в терминах задачи на оптимальное управление. И неудивительно, что вы используете именно их, т.к. и оптимальное управление, и ПНД формулируются в одинаковых математических терминах, а именно как задачи на вариации функционалов и поиска экстремумов. Заметьте, вы специально подбираете параметры «машины» так, чтобы функционал качества для задачи оптимального управления соответствовал функционалу действия. Что, как мне кажется, не сильно упрощает понятие ПНД.
Хотите объяснить «на пальцах» — начните с того, как из ПНД вывести первый закон Ньютона. Это просто, наглядно и требует абсолютного минимума математики.
А если (внезапно) проект востребованный, а разрабочики на нем — так себе?..
Однако же вы делаете главную одну ошибку — относитесь к этому вопросу как приличный программист :-)
Поэтому и зациклились на крупных проектах.
Вы мыслите примерно так: «я сделал классный пакет, вложил кучу сил, и теперь хочу, чтобы он 99% попал в этот вот конкретный крупный проект. Это круто, это + в резюме, да и просто приятно.»
Нам всем это понятно, и всем хочется того же…
А нужно мыслить так: «Я сделал вредоносный пакет и мне все равно в какие пакеты он попадет, лишь бы побольше разных — через зависимости рано или поздно подтянется в большое число реальных, боевых проектов»
Это совершенно другая цель. Абсолютно все равно, заразите ли вы 100 сайтов через один большой пакет или через 50 мелких — вы все равно получите то, что хотите.
И, раз уж вы говорите «слишком сложно», то представьте количество даных, которые будет вам сливать ежедневно условный amazon, если вам удастся его заразить… Уверены, что прокачивание аккаунта и написание хорошего фикса того не стоят?)
Вы утверждаете, что всегда (100%) внедряются только прокачанные пакеты с прокачанных аккаунтов, исключительно с уникальным и полезным функционалом, и никогда не принимаются мелкие изменения?.. Хм.
Вы наерняка знаете, насколько эффективны фишинговые атаки? Да, 99% людей их смогут избежать, но 1 % который попадается, приносит ощутимый профит, настолько большой, что этим продолжают заниматься.
Иными словами.
Самое слабое звено — люди.
Если вы проведете сто мелких изменений слквых аккаунтов, то есть шанс, что одно примут. Ну а дальше масшатбируйте эти числа))
Вы одну крайность опровергаете другой крайностью. «Сразу кодить» и «зубрить мануал» — это просто две стороны одной медали. Нормальная последовательность работы это прочитать как работает один конкретный элемент, а затем немедленно «пощупать» его.
Собственно, я гарантирую, что вы сами так всю жизнь учились.
Ни за что не поверю, что вы не написали HelloWord задолго до того, как изучили C99 ISO :-)
Будьте осторожнее с таким подходом…
Если вы себе представляете работу технарем как бесконечное решение bleeding-edge задач, то вы глубоко заблуждаетесь — вам ПРИДЕТСЯ писать доки, делать презентации, писать тексты фич и отдельных задач, помогать джунам и многое, многое другое. Иными словами, в любой работе огромное(!) количество рутины, от которой вы никуда не денетесь.
А если вздумаете быть ИП, то добавится еще веселья с налогами, договорами и прочим.
Если не можете справиться с рутиной в 9 классе, то, расстрою вас, в будущем сильно проще не станет. И, кстати, ошибки станут стоить вам намного дороже.
Это, конечно, сильно зависит от того, где вы работаете.
Могу сказать за очень крупные компании, которые делают B2B софт - вы становитесь по настоящему senior'ом в глазах компании, когда вы начинаете меньше думать о своем коде и больше - о гораздо более скучных корпоративных вещах.
Достаточно ли у вас ресурсов, насколько высоко в приоритетах стоит конкретная задача, есть ли другие команды в компании с похожими задачами, есть ли крупные пользователи, которые могут заиметь проблемы от вашей классной новой фичи, как будет устроена миграция на новый фреймворк/бд/протокол/вставить свое.
Были некоторые коллеги, гораздо сильнее меня с точки зрения технической, но могли легко "увлечься" созданием идеальной архитектуры для фич, которые никому были не особо нужны. Код прекрасен, но если никто его не использует - то его для компании, считай, не существует...
Попросту говоря - senior это тот, кто может принимать решения, а это крайне редко сводится к чисто техническим аспектам.
Строго говоря, нет. Если вы варьируете их независимо, т.е. посути варьируете координату и импульс — то это уже не лагранжев формализм, а гамильтонов.
Суть в том, что действие есть функционал от траектории q[t], и варьируете вы только обощенную переменную. Ибо больше нечего варьировать :-)
Мне кажется, вы только сильнее запутаете людей, которые не знают что такое ПНД. Все примеры, кроме первого, мне кажутся крайне неудачными, поскольку сформилированы в терминах задачи на оптимальное управление. И неудивительно, что вы используете именно их, т.к. и оптимальное управление, и ПНД формулируются в одинаковых математических терминах, а именно как задачи на вариации функционалов и поиска экстремумов. Заметьте, вы специально подбираете параметры «машины» так, чтобы функционал качества для задачи оптимального управления соответствовал функционалу действия. Что, как мне кажется, не сильно упрощает понятие ПНД.
Хотите объяснить «на пальцах» — начните с того, как из ПНД вывести первый закон Ньютона. Это просто, наглядно и требует абсолютного минимума математики.
Правда, для сотрудников в возрасте не вариант…
Ни разу не выдавали чек за алкоголь, купленный после 23:00)))
Наличный расчет: анонимный, необратимый, мгновенный. В общем, биткойн времен Имхотепа)
Однако же вы делаете главную одну ошибку — относитесь к этому вопросу как приличный программист :-)
Поэтому и зациклились на крупных проектах.
Вы мыслите примерно так: «я сделал классный пакет, вложил кучу сил, и теперь хочу, чтобы он 99% попал в этот вот конкретный крупный проект. Это круто, это + в резюме, да и просто приятно.»
Нам всем это понятно, и всем хочется того же…
А нужно мыслить так: «Я сделал вредоносный пакет и мне все равно в какие пакеты он попадет, лишь бы побольше разных — через зависимости рано или поздно подтянется в большое число реальных, боевых проектов»
Это совершенно другая цель. Абсолютно все равно, заразите ли вы 100 сайтов через один большой пакет или через 50 мелких — вы все равно получите то, что хотите.
И, раз уж вы говорите «слишком сложно», то представьте количество даных, которые будет вам сливать ежедневно условный amazon, если вам удастся его заразить… Уверены, что прокачивание аккаунта и написание хорошего фикса того не стоят?)
Вы наерняка знаете, насколько эффективны фишинговые атаки? Да, 99% людей их смогут избежать, но 1 % который попадается, приносит ощутимый профит, настолько большой, что этим продолжают заниматься.
Иными словами.
Самое слабое звено — люди.
Если вы проведете сто мелких изменений слквых аккаунтов, то есть шанс, что одно примут. Ну а дальше масшатбируйте эти числа))
Собственно, я гарантирую, что вы сами так всю жизнь учились.
Ни за что не поверю, что вы не написали HelloWord задолго до того, как изучили C99 ISO :-)
Если вы себе представляете работу технарем как бесконечное решение bleeding-edge задач, то вы глубоко заблуждаетесь — вам ПРИДЕТСЯ писать доки, делать презентации, писать тексты фич и отдельных задач, помогать джунам и многое, многое другое. Иными словами, в любой работе огромное(!) количество рутины, от которой вы никуда не денетесь.
А если вздумаете быть ИП, то добавится еще веселья с налогами, договорами и прочим.
Если не можете справиться с рутиной в 9 классе, то, расстрою вас, в будущем сильно проще не станет. И, кстати, ошибки станут стоить вам намного дороже.