Не могу пройти мимо и не поделиться недавней историей моего "собеседования".
Я лет 10 назад уже проходил собесы и даже прошёл... но мне великодушно предложили позицию джуна и зарплату в 2 раза ниже той, что я получал в тот момент ("но ты же понимаешь - это ведь Яндекс!"). И это с 10ю годами опыта за плечами, опытом тимлидства и десятком языков на вооружении. Да, как оказалось всякие параметры и ключи запуска (которые можно найти в справке) я помнил не достаточно хорошо. А до выслушивания моего опыта и просмотра моих проектов интервьюер опускаться не захотел - не барское это дело - его дело демонстрировать своё эго и ВАЛИть тех кто не понравился... Это тогда прям сильно меня зацепило, но на обиженных, как известно, воду возят, потому постарался забыть.
Пол года назад, раз уж я искал новую работу, - решил спросить нет ли интересных вакансий в Яндексе. Ко мне пришёл рекрутер, час меня допрашивал про мой опыт и навыки, сказал что пошёл искать подходящие варианты и..... пропал. Просто тишина, даже не счёл нужным ничего написать.
От былого величия и половины не осталось, а флёр снобизма, пренебрежения и снисхождения пышет из всех щелей до сих пор. Тьфу, одним словом.
Проблема не а том, что вы что-то упустили, а в том, что момент когда нейросеть сможет переписать с одного языка на другой без потери производительности (и вообще что-либо больше скрипта на 200 строк) - ещё не наступил.
Да, я это тоже видел. Ник у аккаунта "manager" - можно предположить, что кто-то выкладывает истории сотрудников своей компании. Но выглядит всё это как сгенерированная через нейросеть подборка с рекламной вставкой.
Мне одному кажется, что это вымышленная история, составленная только ради упоминания базы знаний MinervaKnowledge??? Один сплошной набор клише и рандомных картинок. Как, впрочем, и все остальные статьи этого автора.
Ну вот сразу бы так и говорили - эти я каждый день по 5 штук проектирую!
В малом бизнесе который через 5 лет может и прекратить своё существование
Малый бизнес - это когда хорошо если он дожил до запуска. А уже если год просуществовал - это почти мечта.
Ну а если приводить в пример "масштабные проекты" - посмотрите, например, на то как делают SpaceX - они не проектируют ракету 10 лет как Королёв в шарашке. Вместо этого они по несколько раз в год запускают прототипы и постепенно отлаживают и софт, и железо, и процессы.
И сам тезис, и все приведённые далее требования - это из советского подхода "10 лет проектируем, 5 лет делаем, ещё 5 лет отлаживаем, а потом 50 лет пользуемся".
Этот подход больше невозможен (я не уверен, что он и тогда то был правильным). Всё это должно быть непрерывным итеративным процессом, способным максимально быстро подстраиваться под изменения окружающей нас реальности. А реальность изменяется молниеносно.
15 команд одновременно занимаются разработкой пользовательской ОС - это просто нерациональная трата ресурсов
Категорически не согласен. Взгляните даже в СССР - сколько было разных КБ (в.т.ч. оборонных) одного и того же профиля. Между ними постоянно была конкуренция, каждый новый заказ был конкурсным. Иначе как раз будет одно единственное еле-еле работающее решение, которое никому не нужно доводить до ума просто потому, что альтренатив нет, "и так схавают". Что мы и наблюдаем сейчас во многих сферах отечественного производства.
Ага, ага, конечно. Особенно когда у тебя нет отдельной комнаты для работы, а вокруг скачут мелкие дети и тянут за шнур зарядки ноутбука.
пока удаленщик в принципе в состоянии организовать себя
И да, я способен себя организовать — несколько лет подряд работал удалённо в отдельной съёмной квартире (с холодильником, кроватью и что там ещё отвлекает по рассказам) в полном уединении. И получалось вполне продуктивно. Но через какое‑то время начинаешь выть от дефицита общения с живыми людьми.
А сейчас скооперировался с бывшими коллегами и снимаем небольшой офис в центре города (провинциального, время до работы около 15 минут) и пока всем очень доволен.
организовать себя для удаленной работы могут не только лишь все
Поменьше снобизма, коллега. У всех разные жизненные условия.
cli - это лишь интерфейс. Цимес всего этого в платформе, на которой реализованы и валидация контрактов, и всё остальное. Открыть такую систему наружу очень сложно, потому что чаще всего всё прибито гвоздями и куча специфики/легаси и т.п. Потому подозреваю, что примерно "никогда" :(
"без GC" мне на ум приходят разве что c/c++ и rust из более-менее популярных. Вы правда пишете любой бэкенд сервис на одном из вышеперечисленных языков? Очень необычный выбор. Мне кажется, что в этом сегменте довольно давно правят баллом Java и C#.
Ну и ещё стоит посмотреть в сторону популярных ныне NATS, Centrifugo, Traefik, Prometheus/VictoriaMetrics, Consul, Vault - уж куда более "сетевых" продуктов трудно найти. И все они на go.
Да, с закрытием контекста не всё так просто. Часто чтобы обработать реквест нужно сходить в базу данных. И вот если сигнал остановки пришёл между получением запроса и ещё до похода в базу - мы пойдём в базу с просроченным контекстом. В результате в метриках мы увидим ошибку, хотя ничего нестандартного и не происходило.
В случае с веб сервером отмена контекста на самом деле и не очень то нужна. Ведь обработка http запросов (не websocket) предполагает, что мы получили реквест, отдали данные и завершили работу. Так что тут будет достаточно вызвать стандартный Shutdown самого сервера и все его хэндлеры вскоре завершаться сами собой.
А вот с воркерами история немного другая. Лично я предпочитаю передавать в воркеры не только контекст, но и ещё сигнальный канал (один на всё приложение). Соответственно воркеры в селекте проверяют не ctx.Done(), а именно этот сигнальный канал.
Пример:
func main() {
ctx, cancel := context.WithCancel(context.Background())
defer cancel()
closing := make(chan bool) // signal channel
wg := &sync.WaitGroup{}
wg.Add(1)
go func(ctx context.Context, closing chan bool) {
defer wg.Done()
ticker := time.NewTicker(time.Second)
for {
select {
case <-closing:
return
case <-ticker.C:
// do some work, ctx is always valid
fmt.Println("something")
}
}
}(ctx, closing)
c := make(chan os.Signal, 1)
signal.Notify(c, os.Interrupt, syscall.SIGTERM)
<-c // wait for stop signal
close(closing) // initiate graceful shutdown
wg.Wait() // wait until workers are done
}
Да, кода получается больше и здесь ещё нет обработки ошибок в воркерах и не обрабатывается ситуация, когда воркеры не завершились за отведённое время. Но в целом идея примерно такая. Зато при редеплое приложения вы не обнаружите на графиках кучу ошибок, взявшихся неизвестно откуда.
Удивляет меня несколько этот вопрос. "для такой задачи" это какой?) Просто похоже, вас сильно пугает наличие gc как факт, хоть ведь та же java (на которой, например, написана весь производительная kafka) - тоже использует gc. Ну и в целом Go был создан гуглом на замену C++ для написания сетевых сервисов. И сеть - это прям конёк гошки, она почти идеальная для написания бэкенда.
Интересно, откуда такое безапелляционное утверждение? Мы у себя рассматривали NATS как альтернативу другим брокерам и производительность у него оказалась не фонтан. Вдобавок, некоторые вещи у него конфигурируются только при старте (реврайты для JetStream в частности). Плюс нашли пару багов, которые зарепортили и их подтвердили. В итоге NATS видится неплохим решением для небольших компаний и не очень больших нагрузок. Да, он минималистичен и прост, поддерживает много всего, но лично для нас это не было целевыми показателями, а по ключевым он не вывез(
Я работал удалённо несколько лет и вот сейчас уже больше года из дома работаю. И я очень хочу вернуться в офис — просто не по мне это сидеть одному целыми днями. Я не социофоб и чувствую себя комфортно в коллективе. А другим нооборот — дома спокойнее и продуктивнее. Да и время до работы — это актуально тем кто живёт в больших городах. А в моём провинциальном городе до работы ехать 10-15 минут.
Так что не во времени едином дело.
У меня вопрос к автору и модераторам — почему в данном случае выбран хаб «разработка»? То, что нужная модель просимулирована на python ещё не означает, что вся статья про разработку. А то так можно написать статью про использование photoshop, а в конце приписать, что был написан скрипт в 2 строки для автоматического сохранения промежуточных состояний каждый 10 минут и статья будет про «разработку»?
И теперь вопрос по сути статьи: Правильно ли я понимаю, что вся методика анализа эффективности стратегии строится на предположении, что курс на рынке — величина случайна?
Из этого следует, что методика предназначена для определения эффективности стратегии, применённой к случайному процессу.В реальности же процесс случайным не является, а следовательно эффективность «случайного» трейдера на таком процессе не подчиняется вышеуказанным формулам. А значит и сравнивать с ними не совсем корректно. По-моему это как раз и получается сравнение реальной системы на реальном рынке со «сферическим» трейдером на «сферическом» рынке.
Я не дизайнер, а программист и непосредственно дизайн меня не так задевает, как юзабилити. И в свете этого мне совсем непонятно, почему favicon'ы показываются только в яндексе, но не в гугле или бинге. По-моему это очень удобно и я часто ориентируюсь по выдаче именно при помощи них. Скажем, если я хочу найти фильм и посмотреть трейлер, — я инстинктивно ищу иконку кинопоиска среди результатов и практически безошибочно его нахожу даже не читая текст.
Или я что-то неправильно понимаю и такие подсказки противоречат правилам хорошего дизайна и ux?
Не могу пройти мимо и не поделиться недавней историей моего "собеседования".
Я лет 10 назад уже проходил собесы и даже прошёл... но мне великодушно предложили позицию джуна и зарплату в 2 раза ниже той, что я получал в тот момент ("но ты же понимаешь - это ведь Яндекс!"). И это с 10ю годами опыта за плечами, опытом тимлидства и десятком языков на вооружении. Да, как оказалось всякие параметры и ключи запуска (которые можно найти в справке) я помнил не достаточно хорошо. А до выслушивания моего опыта и просмотра моих проектов интервьюер опускаться не захотел - не барское это дело - его дело демонстрировать своё эго и ВАЛИть тех кто не понравился... Это тогда прям сильно меня зацепило, но на обиженных, как известно, воду возят, потому постарался забыть.
Пол года назад, раз уж я искал новую работу, - решил спросить нет ли интересных вакансий в Яндексе. Ко мне пришёл рекрутер, час меня допрашивал про мой опыт и навыки, сказал что пошёл искать подходящие варианты и..... пропал. Просто тишина, даже не счёл нужным ничего написать.
От былого величия и половины не осталось, а флёр снобизма, пренебрежения и снисхождения пышет из всех щелей до сих пор. Тьфу, одним словом.
Проблема не а том, что вы что-то упустили, а в том, что момент когда нейросеть сможет переписать с одного языка на другой без потери производительности (и вообще что-либо больше скрипта на 200 строк) - ещё не наступил.
Как гордо звучит! А вы сами что-нибудь писать пробовали?
Там все цифры на экране были
Да, я это тоже видел. Ник у аккаунта "manager" - можно предположить, что кто-то выкладывает истории сотрудников своей компании.
Но выглядит всё это как сгенерированная через нейросеть подборка с рекламной вставкой.
Мне одному кажется, что это вымышленная история, составленная только ради упоминания базы знаний MinervaKnowledge??? Один сплошной набор клише и рандомных картинок. Как, впрочем, и все остальные статьи этого автора.
Я пока ещё ни одной не спроектировал. А вы?
Ну вот сразу бы так и говорили - эти я каждый день по 5 штук проектирую!
Малый бизнес - это когда хорошо если он дожил до запуска. А уже если год просуществовал - это почти мечта.
Ну а если приводить в пример "масштабные проекты" - посмотрите, например, на то как делают SpaceX - они не проектируют ракету 10 лет как Королёв в шарашке. Вместо этого они по несколько раз в год запускают прототипы и постепенно отлаживают и софт, и железо, и процессы.
И сам тезис, и все приведённые далее требования - это из советского подхода "10 лет проектируем, 5 лет делаем, ещё 5 лет отлаживаем, а потом 50 лет пользуемся".
Этот подход больше невозможен (я не уверен, что он и тогда то был правильным). Всё это должно быть непрерывным итеративным процессом, способным максимально быстро подстраиваться под изменения окружающей нас реальности. А реальность изменяется молниеносно.
Категорически не согласен. Взгляните даже в СССР - сколько было разных КБ (в.т.ч. оборонных) одного и того же профиля. Между ними постоянно была конкуренция, каждый новый заказ был конкурсным. Иначе как раз будет одно единственное еле-еле работающее решение, которое никому не нужно доводить до ума просто потому, что альтренатив нет, "и так схавают". Что мы и наблюдаем сейчас во многих сферах отечественного производства.
Ага, ага, конечно. Особенно когда у тебя нет отдельной комнаты для работы, а вокруг скачут мелкие дети и тянут за шнур зарядки ноутбука.
И да, я способен себя организовать — несколько лет подряд работал удалённо в отдельной съёмной квартире (с холодильником, кроватью и что там ещё отвлекает по рассказам) в полном уединении. И получалось вполне продуктивно. Но через какое‑то время начинаешь выть от дефицита общения с живыми людьми.
А сейчас скооперировался с бывшими коллегами и снимаем небольшой офис в центре города (провинциального, время до работы около 15 минут) и пока всем очень доволен.
Поменьше снобизма, коллега. У всех разные жизненные условия.
cli - это лишь интерфейс. Цимес всего этого в платформе, на которой реализованы и валидация контрактов, и всё остальное. Открыть такую систему наружу очень сложно, потому что чаще всего всё прибито гвоздями и куча специфики/легаси и т.п. Потому подозреваю, что примерно "никогда" :(
"без GC" мне на ум приходят разве что c/c++ и rust из более-менее популярных. Вы правда пишете любой бэкенд сервис на одном из вышеперечисленных языков? Очень необычный выбор. Мне кажется, что в этом сегменте довольно давно правят баллом Java и C#.
Ну и ещё стоит посмотреть в сторону популярных ныне NATS, Centrifugo, Traefik, Prometheus/VictoriaMetrics, Consul, Vault - уж куда более "сетевых" продуктов трудно найти. И все они на go.
Да, с закрытием контекста не всё так просто. Часто чтобы обработать реквест нужно сходить в базу данных. И вот если сигнал остановки пришёл между получением запроса и ещё до похода в базу - мы пойдём в базу с просроченным контекстом. В результате в метриках мы увидим ошибку, хотя ничего нестандартного и не происходило.
В случае с веб сервером отмена контекста на самом деле и не очень то нужна. Ведь обработка http запросов (не websocket) предполагает, что мы получили реквест, отдали данные и завершили работу. Так что тут будет достаточно вызвать стандартный Shutdown самого сервера и все его хэндлеры вскоре завершаться сами собой.
А вот с воркерами история немного другая. Лично я предпочитаю передавать в воркеры не только контекст, но и ещё сигнальный канал (один на всё приложение). Соответственно воркеры в селекте проверяют не ctx.Done(), а именно этот сигнальный канал.
Пример:
Да, кода получается больше и здесь ещё нет обработки ошибок в воркерах и не обрабатывается ситуация, когда воркеры не завершились за отведённое время. Но в целом идея примерно такая.
Зато при редеплое приложения вы не обнаружите на графиках кучу ошибок, взявшихся неизвестно откуда.
Удивляет меня несколько этот вопрос. "для такой задачи" это какой?)
Просто похоже, вас сильно пугает наличие gc как факт, хоть ведь та же java (на которой, например, написана весь производительная kafka) - тоже использует gc.
Ну и в целом Go был создан гуглом на замену C++ для написания сетевых сервисов. И сеть - это прям конёк гошки, она почти идеальная для написания бэкенда.
Интересно, откуда такое безапелляционное утверждение?
Мы у себя рассматривали NATS как альтернативу другим брокерам и производительность у него оказалась не фонтан. Вдобавок, некоторые вещи у него конфигурируются только при старте (реврайты для JetStream в частности). Плюс нашли пару багов, которые зарепортили и их подтвердили.
В итоге NATS видится неплохим решением для небольших компаний и не очень больших нагрузок. Да, он минималистичен и прост, поддерживает много всего, но лично для нас это не было целевыми показателями, а по ключевым он не вывез(
Так что не во времени едином дело.
И теперь вопрос по сути статьи: Правильно ли я понимаю, что вся методика анализа эффективности стратегии строится на предположении, что курс на рынке — величина случайна?
Из этого следует, что методика предназначена для определения эффективности стратегии, применённой к случайному процессу.В реальности же процесс случайным не является, а следовательно эффективность «случайного» трейдера на таком процессе не подчиняется вышеуказанным формулам. А значит и сравнивать с ними не совсем корректно. По-моему это как раз и получается сравнение реальной системы на реальном рынке со «сферическим» трейдером на «сферическом» рынке.
Или я что-то неправильно понимаю и такие подсказки противоречат правилам хорошего дизайна и ux?