Коммент немного не по теме, но я тут от скуки залез на Хабр и наткнувшись на вашу статью, череда кликов по ссылкам привела меня к тому, что я прочитал все ваши статьи 😅 В итоге уже знаю, где буду запускать свои проекты и сервак Minecraft для игры с друзьями по выходным) А если серьёзно, то вы молодцы. Крутой проект и очень интересно следить за закулисьем процесса старта.
Вы чего, GORM в прод засунули? Он по сути только для прототипирования и годится. Предвкушаю море хейта от тех, кто не любит писать запросы ручками и сразу обрисую свою позицию. Разрабатывая бэк, мы в 99% получаем приложение с IO bound нагрузкой. Это значит, что сервис тратит больше всего времени на обмен данными с чем бы то ни было. А ORM системы из-за дополнительных абстракций, а зачастую ещё и используя рефлексию, заметно увеличивают время обработки запроса. Перед релизом можно и нужно реализовывать репо используя запросы написанные ручками и хороший драйвер. Я не говорю, что ORM не нужно использовать. Скорее наоборот, если тебе нужно быстренькое и на коленках накидать прототип решения, то это отличный выбор, но не в прод)
Почитай про изменения пакета net/http в Go 1.22. Теперь можно задавать отдельные обработчики для каждого метода вот таким образом mux.HandleFunc("POST /form", postFormHandler). На самом деле там ещё много интересных нововведений, которые позволяют полностью отказаться от сторонних роутеров на подобии chi.
Я не понял зачем автор использовал тут указатель, это и правда похоже на сгенеренный нейронкой пост. Но на практике (по крайней мере в моей компании) обычно структура http сервера встраивается в другую структуру. И там используется указатель, чтобы при вероятном копировании конечной структуры не происходило копирование http сервера.
Расскажу, как это ощущается с позиции соискателя на как раз таки начальную позицию (Junior+ / entry Middle). Прошу прощение за многословность, но иначе никак.
Самая большая трудность, это конечно пройти HR фильтр. Так как из-за обилия откликов и неумения с этим работать, HR не тратит больше минуты на просмотр резюме, дойти до технического интервью крайне сложно. За последние 3 месяца я попал только на 5 интервью с HR и 4 технических интервью. В остальных случаях это был либо игнор, либо отказ в ту же минуту, как компания просмотрела моё резюме. В одном случае был отказ из-за недостатка коммерческого опыта (у меня чуть больше года, а в вакансии просили год), в оставшихся 4 я спокойно дошел до технической части.
Ни в одном из интервью не было проверки на знание алгоритмов или структур данных. Да и правда не так часто их приходится реализовывать, чтобы постоянно держать в голове.
Первое интервью можно назвать техническим в кавычках, так как проводил его человек не знающий темы. Это был просто опросник по заранее подготовленной табличке с вопросами касательно разных нетривиальных нюансов синтаксиса. В итоге я не смог получить от них обратную связь, но меня забрили. Хотя вопросы были достаточно простые и я сомневаюсь, что где-то ошибался. Возможно из-за волнения, ведь я тоже начинаю мямлить в стрессовой ситуации.
Второе интервью было тоже достаточно странным. Там был уже настоящий разработчик, но как я понял, он тоже слабо знает язык, указанный в вакансии (Если кому интересно, то это Go). Здесь к моему опыту вопросов не было. Меня сначала закидали вопросами по предыдущей работе, по нюансам реализации конкретных модулей и так далее. Но когда дело дошло до проверки знания стандартной библиотеки, тут появился неожиданный нюанс. На вопрос, как можно запустить в один момент N кол-во потоков (да, я знаю, что горутины, это не потоки, но и Go не все знают, так что упрощаем), я ответил, что это невозможно, ведь так оно и есть, этим делом рулит рантайм. На что получил комментарий, что я ничего не знаю и вообще там есть структура WaitGroup, у которой есть метод запуска нескольких горутин..... И так далее.... Я попытался оспорить это, рассказал как работает эта структура, для чего она нужна и предложил открыть документацию, на что был послан со словами "я и так всё знаю, там точно такое есть, документацию смотреть не будем". Либо я оказался слишком наглым, что посмел поправить тим-лида, либо что-то ещё, но как вы понимаете, получил отказ.
С третьим интервью всё было быстрее и проще. Интервьюер решил применить крайне странную тактику, которая заключалась в немедленном ответе на вопрос не задумываясь. Большая часть вопросов касалась языка и классического стека Redis, Docker, Postgres, но и малознакомые темы тоже были, например шифрование. Местами я просто не успевал сформулировать ответ из-за стресса, как слышал фразу "долго думаешь, значит не знаешь. Идем дальше". Пару раз отвечал неправильно, хотя знал правильный ответ, но доходило до меня это уже позже. В итоге провал с формулировкой "нулевые знания".
В четвертом случае, это скорее не техническое интервью, а просто результат проверки тестового задания. Причем задание было достаточно объемное, на что у меня ушла неделя времени (примерно по 10 - 12 часов в сутки), чтобы не просто написать рабочий прототип, а готовое решение. После отправки задания на проверку я начал готовиться к сессии зашиты, но получил письмо с примерно следующим содержанием: "Знаешь язык, знаешь технологии, но вот нам не понравилось, как ты методы именуешь в нескольких местах и у тебя не чистая архитектура, так как в паре мест прямой юз зависимостей минуя интерфейсы. Грейд ниже ожидаемого, отказ." Даже без диалога, сразу отказ. К слову архитектурных требований не было, как и стайл гайда. Обычно реализуя тестовые задания, люди опираются на предыдущий опыт. Я никак не могу знать, как у них принято именовать методы или что мне нужно было использовать только чистую архитектуру. Да и касательно повсеместного использования интерфейсов, это не даст хев. Из того, что я вижу, тренд идет к отказу от этого дела.
В итоге просто продолжаю поиск, в основном получая отказы в ту же минуту, как hr открыл резюме.
Спасибо за интересный материал! Кажется нашел занятие на выходные, написать power gadgets нормального человека) Интересно, как можно ещё получать метрики системы, помимо вызова powermetrics? Он как никак больше похож на тулзу для конечного пользователя, нежели промежуточный инструмент.
Почему бы не использовать некого "прокси" бота для личных ботов дабы не так быстро расходовать лимит на них и не засорять список чатов? Да, нужно будет обдумать как сделать более удобную навигацию и переключение контекста в некоторых случаях, но у bot API полно методов позволяющих сделать это без вреда для опыта использования.
Коммент немного не по теме, но я тут от скуки залез на Хабр и наткнувшись на вашу статью, череда кликов по ссылкам привела меня к тому, что я прочитал все ваши статьи 😅
В итоге уже знаю, где буду запускать свои проекты и сервак Minecraft для игры с друзьями по выходным)
А если серьёзно, то вы молодцы. Крутой проект и очень интересно следить за закулисьем процесса старта.
У Вас кстати сайт не открывается
Вы чего, GORM в прод засунули?
Он по сути только для прототипирования и годится.
Предвкушаю море хейта от тех, кто не любит писать запросы ручками и сразу обрисую свою позицию.
Разрабатывая бэк, мы в 99% получаем приложение с IO bound нагрузкой. Это значит, что сервис тратит больше всего времени на обмен данными с чем бы то ни было. А ORM системы из-за дополнительных абстракций, а зачастую ещё и используя рефлексию, заметно увеличивают время обработки запроса. Перед релизом можно и нужно реализовывать репо используя запросы написанные ручками и хороший драйвер.
Я не говорю, что ORM не нужно использовать. Скорее наоборот, если тебе нужно быстренькое и на коленках накидать прототип решения, то это отличный выбор, но не в прод)
Почитай про изменения пакета net/http в Go 1.22.
Теперь можно задавать отдельные обработчики для каждого метода вот таким образом mux.HandleFunc("POST /form", postFormHandler).
На самом деле там ещё много интересных нововведений, которые позволяют полностью отказаться от сторонних роутеров на подобии chi.
Я не понял зачем автор использовал тут указатель, это и правда похоже на сгенеренный нейронкой пост.
Но на практике (по крайней мере в моей компании) обычно структура http сервера встраивается в другую структуру. И там используется указатель, чтобы при вероятном копировании конечной структуры не происходило копирование http сервера.
Мне одному кажется, что автор и на комменты отвечает как LLM? Вероятно чей-то эксперимент. Кстати мне нравится)
Расскажу, как это ощущается с позиции соискателя на как раз таки начальную позицию (Junior+ / entry Middle). Прошу прощение за многословность, но иначе никак.
Самая большая трудность, это конечно пройти HR фильтр. Так как из-за обилия откликов и неумения с этим работать, HR не тратит больше минуты на просмотр резюме, дойти до технического интервью крайне сложно. За последние 3 месяца я попал только на 5 интервью с HR и 4 технических интервью. В остальных случаях это был либо игнор, либо отказ в ту же минуту, как компания просмотрела моё резюме. В одном случае был отказ из-за недостатка коммерческого опыта (у меня чуть больше года, а в вакансии просили год), в оставшихся 4 я спокойно дошел до технической части.
Ни в одном из интервью не было проверки на знание алгоритмов или структур данных. Да и правда не так часто их приходится реализовывать, чтобы постоянно держать в голове.
Первое интервью можно назвать техническим в кавычках, так как проводил его человек не знающий темы. Это был просто опросник по заранее подготовленной табличке с вопросами касательно разных нетривиальных нюансов синтаксиса. В итоге я не смог получить от них обратную связь, но меня забрили. Хотя вопросы были достаточно простые и я сомневаюсь, что где-то ошибался. Возможно из-за волнения, ведь я тоже начинаю мямлить в стрессовой ситуации.
Второе интервью было тоже достаточно странным. Там был уже настоящий разработчик, но как я понял, он тоже слабо знает язык, указанный в вакансии (Если кому интересно, то это Go). Здесь к моему опыту вопросов не было. Меня сначала закидали вопросами по предыдущей работе, по нюансам реализации конкретных модулей и так далее. Но когда дело дошло до проверки знания стандартной библиотеки, тут появился неожиданный нюанс. На вопрос, как можно запустить в один момент N кол-во потоков (да, я знаю, что горутины, это не потоки, но и Go не все знают, так что упрощаем), я ответил, что это невозможно, ведь так оно и есть, этим делом рулит рантайм. На что получил комментарий, что я ничего не знаю и вообще там есть структура WaitGroup, у которой есть метод запуска нескольких горутин..... И так далее.... Я попытался оспорить это, рассказал как работает эта структура, для чего она нужна и предложил открыть документацию, на что был послан со словами "я и так всё знаю, там точно такое есть, документацию смотреть не будем". Либо я оказался слишком наглым, что посмел поправить тим-лида, либо что-то ещё, но как вы понимаете, получил отказ.
С третьим интервью всё было быстрее и проще. Интервьюер решил применить крайне странную тактику, которая заключалась в немедленном ответе на вопрос не задумываясь. Большая часть вопросов касалась языка и классического стека Redis, Docker, Postgres, но и малознакомые темы тоже были, например шифрование. Местами я просто не успевал сформулировать ответ из-за стресса, как слышал фразу "долго думаешь, значит не знаешь. Идем дальше". Пару раз отвечал неправильно, хотя знал правильный ответ, но доходило до меня это уже позже. В итоге провал с формулировкой "нулевые знания".
В четвертом случае, это скорее не техническое интервью, а просто результат проверки тестового задания. Причем задание было достаточно объемное, на что у меня ушла неделя времени (примерно по 10 - 12 часов в сутки), чтобы не просто написать рабочий прототип, а готовое решение. После отправки задания на проверку я начал готовиться к сессии зашиты, но получил письмо с примерно следующим содержанием: "Знаешь язык, знаешь технологии, но вот нам не понравилось, как ты методы именуешь в нескольких местах и у тебя не чистая архитектура, так как в паре мест прямой юз зависимостей минуя интерфейсы. Грейд ниже ожидаемого, отказ." Даже без диалога, сразу отказ. К слову архитектурных требований не было, как и стайл гайда. Обычно реализуя тестовые задания, люди опираются на предыдущий опыт. Я никак не могу знать, как у них принято именовать методы или что мне нужно было использовать только чистую архитектуру. Да и касательно повсеместного использования интерфейсов, это не даст хев. Из того, что я вижу, тренд идет к отказу от этого дела.
В итоге просто продолжаю поиск, в основном получая отказы в ту же минуту, как hr открыл резюме.
Это кстати странно, но у меня уже несколько недель как нет проблем с YouTube у домашнего провайдера. Если кому интересно, то это Етелеком, СПБ.
Спасибо за интересный материал! Кажется нашел занятие на выходные, написать power gadgets нормального человека)
Интересно, как можно ещё получать метрики системы, помимо вызова powermetrics? Он как никак больше похож на тулзу для конечного пользователя, нежели промежуточный инструмент.
Почему бы не использовать некого "прокси" бота для личных ботов дабы не так быстро расходовать лимит на них и не засорять список чатов? Да, нужно будет обдумать как сделать более удобную навигацию и переключение контекста в некоторых случаях, но у bot API полно методов позволяющих сделать это без вреда для опыта использования.