Как я понял, генератор TypeScript интерфейса просто переложили с фронта на бэк. Делаться он будет на основе того же описания со swagger. Просто это будет делать разработчик с бэка, когда ему захочется что-то поменять. Фротендеру после этого придется дорабатывать ядро. Суммарное количество затрачиваемого времени на работу не изменилось, просто оно уменьшилось на фронте и увеличилось на бэке. Фронт рапортует об ускорении процесса. По ощущениям, ускорение будет незначительным, так как что там, что там работу делает генератор. А если бэк будет вручную править, то времени придется потратить даже больше. В чем профит для бизнеса? Обработка несуществующих методов может быть решена один раз на стороне бэка выдачей 404 и все.
Возможно я что-то не совсем понял и автор сможет пояснить детали.
Главное чтобы не было такого: "ты и за новичками смотри и свои задачи делай".
Давайте просто поставим себя на место Лизы. Человек очень старается чтобы что? Получить больше работы/ответственности? Скорее всего нет. За старания люди ожидают поощрения. Надо узнать, какого вида поощрения ожидает Лиза. Это может быть премия, повышение зарплаты, публичное признание, похвала или больше возможностей влиять на процесс. Зависит от психологических установок Лизы. Нельзя просто ставить лидом человека, который, возможно, этого не хочет, каким бы он первоклассным специалистом не был. Хотя люди на такое соглашаются, даже если не хотят, потому что такие предложения бывают редко, да и не ударить же в грязь лицом перед начальством. Человека надо хотя бы отправить на отдых. Пока проекты для менеджера на первом месте, люди чувствуют, что они здесь разменная монета и уходят. Лучший совет это не быть менеджером, когда дело касается людей. Представьте, что вы тренер.
Можно просто спросить самого кандидата, нужна ли ему обратная связь независимо от того, будет ли оффер или нет. Сразу снимается вопрос о том, стоит ли это делать. Репутация компании не страдает, кандидат лишний раз не ущемлен и время просто так не тратится.
Рекомендую попробовать общение в нативами. Просто один приятный преподаватель, которые знает только английский, и общение с ним только на нем. Очень эффективно. А то ваш мозг натренирован на связи 'слово->перевод' и совсем не привык к обратной связи 'перевод->слово' (у меня была точно такая же проблема). И уж тем более без общения не будет связи 'смысл->готовая фраза'. За пару десятков часовых занятий ощутимый эффект понимания речи с учётом британского акцента. То есть примерно как стоимость небольшого курса. Никакого индивидуального "супер" курса, просто общение на любые темы и корректировка грамматики, если попросить. Причем какого было мое удивление, когда натив долго не мог проверить на соответствие моей фразы конкретному времени, потому что эти времена есть только в учебниках не для нейтовов, зато очень грамотно объяснял, как это звучит для англоговорящего и как фразу упростить или сказать по-другому. И все без страдания от заучивания.
Переписал за пару минут ваш метод NearestEvent, просто инвертируя условия во всех if'ах, не особо разбираясь в смысле кода. Стало ведь читабельнее?
Для опытного программиста такого рода рефакторинг должен быть в подкорке головного мозга уже при написании кода. Отсюда и выводы работодателя. Их грубость не одобряю.
Код метода NearestEvent
public DateTime NearestEvent(DateTime t1)
{
// цикл проверки каждый раз после корректировки времени, макс. кол-во итераций: 100 + 11 + 31 + 23 + 59 + 59 = 283
while (true)
{
var yearOffset = t1.Year - 2000;
if ((yearOffset < 0) || (yearOffset >= _years.Length))
{
throw new InvalidOperationException("Year out of range");
}
if (_years[yearOffset] <= 0)
{
t1 = new DateTime(t1.Year, 1, 1).AddYears(1);
continue;
}
if (_months[t1.Month - 1] <= 0)
{
t1 = new DateTime(t1.Year, t1.Month, 1).AddMonths(1);
continue;
}
var isLastDayInMonth = t1.Day == DateTime.DaysInMonth(t1.Year, t1.Month);
// 32-й день означает последнее число месяца
if (!(((_days[t1.Day - 1] > 0) || (isLastDayInMonth && (_days[31] > 0))) && (_weekDays[(int)t1.DayOfWeek] > 0)))
{
t1 = new DateTime(t1.Year, t1.Month, t1.Day).AddDays(1);
continue;
}
if (_hours[t1.Hour] <= 0)
{
t1 = new DateTime(t1.Year, t1.Month, t1.Day, t1.Hour, 0, 0).AddHours(1);
continue;
}
if (_minutes[t1.Minute] <= 0)
{
t1 = new DateTime(t1.Year, t1.Month, t1.Day, t1.Hour, t1.Minute, 0).AddMinutes(1);
continue;
}
if (_seconds[t1.Second] <= 0)
{
t1 = new DateTime(t1.Year, t1.Month, t1.Day, t1.Hour, t1.Minute, t1.Second).AddSeconds(1);
continue;
}
var millisecond = t1.Millisecond;
do
{
if (_milliseconds[millisecond] > 0)
{
return new DateTime(t1.Year, t1.Month, t1.Day, t1.Hour, t1.Minute, t1.Second, millisecond);
}
millisecond++;
} while (millisecond < _milliseconds.Length);
}
}
К сожалению, по моему опыту прохождения собеседований, фидбек чаще больше пригодится интервьверам, чем соискателю, если последний уже с опытом. Редко встретишь хорошо продуманный процесс и грамотных людей, чтобы было, как в статье "я очень хочу в вам, посмотрите, я переделал". И вообще это позиция ученика. Зачастую и компаниям, скорее всего, есть чему поучиться у опытного соискателя. Разговор должен быть на равных. Если компания не хочет тратить время на адекватность, зачем к ней хорошо относиться?
Ребята вы все правы. Задачи бизнеса решать надо. Автору не нравится форма работы над задачами бизнеса в столь большом отрыве от того, чем он привык и любит заниматься. Он может готов давать свои консультации, но пусть это будет для него обычным таском в джире.
То, что Сеньора начинают таскать по совещаниям, а особенно на встречи с клиентами, так это из-за больших зарплат в мире ИТ и экономии на персонале (хватило денег на одного Сеньора). Если эти зарплаты для бизнеса норма, он нормально распределит обязанности по должностям. И обьяснять бизнесу, когда он не прав, уже будет менеджер, у которого достаточная квалификация в разработке. Сравнимая с Сеньором. Но менеджеров таких нанять готов и может не каждый бизнес. Вместо этого начинает происходить то, о чем написал автор. Бизнес хитрым образом размыл границы и выкрутился, а теперь сделал это нормой.
Когда менеджер приводит программиста к заказчику, то такого менеджера надо уволить, потому что он переносит ответственность в эффективности совещания на программиста. Лучше нанять менеджера, который вышел из такого Сеньора, готов брать ответственность за процесс и способен чувствовать риски и выяснять их заранее у команды разработки, не отвлекая их от своего процесса.
Автору стоит устроиться куда-нибудь подальше от России, где экономия на персонале не произошла в таких масштабах, как у нас, и поэтому нет таких процессов.
Спасибо, стало понятнее. Я правильно понял, что без MCTS нейронная сеть не смогла бы научиться так играть? Возможно ли обучение сети без MCTS на сырых поначалу случайных ходах и без построения дерева?
Люди добрые, может кто-нибудь объяснить мне вот эти моменты? Очень хочу понять весь алгоритм, но для меня он пока сложноват (хоть и совсем на пальцах). Буду очень признателен =)
U — добавка, стимулирующая поиск новых путей; она больше в начале тренировки и меньше — в дальнейшем
Каким образом она меняется? Как захочется разработчику?
очень похоже на cross-entropy loss...
В статье очень мало об этом. Что такое кросс-этропия? Зачем она здесь? Прошу прощения, если я выгляжу невежественно, никогда не встречал это.
Создаёт дочерние ноды с P согласно p
Создает до конца дерева? По одному ноду за проход? Как это связано с P?
Некоторые фразы туманно воспринимаются. Мой уровень очень далек от авторского, чтобы сразу понять, что он имеет в виду.
Как я понял, генератор TypeScript интерфейса просто переложили с фронта на бэк. Делаться он будет на основе того же описания со swagger. Просто это будет делать разработчик с бэка, когда ему захочется что-то поменять. Фротендеру после этого придется дорабатывать ядро. Суммарное количество затрачиваемого времени на работу не изменилось, просто оно уменьшилось на фронте и увеличилось на бэке. Фронт рапортует об ускорении процесса. По ощущениям, ускорение будет незначительным, так как что там, что там работу делает генератор. А если бэк будет вручную править, то времени придется потратить даже больше. В чем профит для бизнеса? Обработка несуществующих методов может быть решена один раз на стороне бэка выдачей 404 и все.
Возможно я что-то не совсем понял и автор сможет пояснить детали.
На работе как-то встретили в своем же коде двухгодичной давности.
// TODO: подумать
Долго думали, о чем надо было подумать, так и не поняли :)
Главное чтобы не было такого: "ты и за новичками смотри и свои задачи делай".
Давайте просто поставим себя на место Лизы. Человек очень старается чтобы что? Получить больше работы/ответственности? Скорее всего нет. За старания люди ожидают поощрения. Надо узнать, какого вида поощрения ожидает Лиза. Это может быть премия, повышение зарплаты, публичное признание, похвала или больше возможностей влиять на процесс. Зависит от психологических установок Лизы. Нельзя просто ставить лидом человека, который, возможно, этого не хочет, каким бы он первоклассным специалистом не был. Хотя люди на такое соглашаются, даже если не хотят, потому что такие предложения бывают редко, да и не ударить же в грязь лицом перед начальством. Человека надо хотя бы отправить на отдых. Пока проекты для менеджера на первом месте, люди чувствуют, что они здесь разменная монета и уходят. Лучший совет это не быть менеджером, когда дело касается людей. Представьте, что вы тренер.
Можно просто спросить самого кандидата, нужна ли ему обратная связь независимо от того, будет ли оффер или нет. Сразу снимается вопрос о том, стоит ли это делать. Репутация компании не страдает, кандидат лишний раз не ущемлен и время просто так не тратится.
Рекомендую попробовать общение в нативами. Просто один приятный преподаватель, которые знает только английский, и общение с ним только на нем. Очень эффективно. А то ваш мозг натренирован на связи 'слово->перевод' и совсем не привык к обратной связи 'перевод->слово' (у меня была точно такая же проблема). И уж тем более без общения не будет связи 'смысл->готовая фраза'. За пару десятков часовых занятий ощутимый эффект понимания речи с учётом британского акцента. То есть примерно как стоимость небольшого курса. Никакого индивидуального "супер" курса, просто общение на любые темы и корректировка грамматики, если попросить. Причем какого было мое удивление, когда натив долго не мог проверить на соответствие моей фразы конкретному времени, потому что эти времена есть только в учебниках не для нейтовов, зато очень грамотно объяснял, как это звучит для англоговорящего и как фразу упростить или сказать по-другому. И все без страдания от заучивания.
Для опытного программиста такого рода рефакторинг должен быть в подкорке головного мозга уже при написании кода. Отсюда и выводы работодателя. Их грубость не одобряю.
Маловато информации про принцип работы. Стоило назвать статью "пример скрипта для генерации структуры папок в Godot".
В любом случае, ожидал, что в статье будет информация шире или детальнее, чем в официальной документации. Но не вышло.
К сожалению, по моему опыту прохождения собеседований, фидбек чаще больше пригодится интервьверам, чем соискателю, если последний уже с опытом. Редко встретишь хорошо продуманный процесс и грамотных людей, чтобы было, как в статье "я очень хочу в вам, посмотрите, я переделал". И вообще это позиция ученика. Зачастую и компаниям, скорее всего, есть чему поучиться у опытного соискателя. Разговор должен быть на равных. Если компания не хочет тратить время на адекватность, зачем к ней хорошо относиться?
Ребята вы все правы. Задачи бизнеса решать надо. Автору не нравится форма работы над задачами бизнеса в столь большом отрыве от того, чем он привык и любит заниматься. Он может готов давать свои консультации, но пусть это будет для него обычным таском в джире.
То, что Сеньора начинают таскать по совещаниям, а особенно на встречи с клиентами, так это из-за больших зарплат в мире ИТ и экономии на персонале (хватило денег на одного Сеньора). Если эти зарплаты для бизнеса норма, он нормально распределит обязанности по должностям. И обьяснять бизнесу, когда он не прав, уже будет менеджер, у которого достаточная квалификация в разработке. Сравнимая с Сеньором. Но менеджеров таких нанять готов и может не каждый бизнес. Вместо этого начинает происходить то, о чем написал автор. Бизнес хитрым образом размыл границы и выкрутился, а теперь сделал это нормой.
Когда менеджер приводит программиста к заказчику, то такого менеджера надо уволить, потому что он переносит ответственность в эффективности совещания на программиста. Лучше нанять менеджера, который вышел из такого Сеньора, готов брать ответственность за процесс и способен чувствовать риски и выяснять их заранее у команды разработки, не отвлекая их от своего процесса.
Автору стоит устроиться куда-нибудь подальше от России, где экономия на персонале не произошла в таких масштабах, как у нас, и поэтому нет таких процессов.
Каким образом она меняется? Как захочется разработчику?
В статье очень мало об этом. Что такое кросс-этропия? Зачем она здесь? Прошу прощения, если я выгляжу невежественно, никогда не встречал это.
Создает до конца дерева? По одному ноду за проход? Как это связано с P?
Некоторые фразы туманно воспринимаются. Мой уровень очень далек от авторского, чтобы сразу понять, что он имеет в виду.