Software developer
Каждый из нас так или иначе сталкивается с техническими собеседованиями: кто-то их проходит, а кто-то - проводит. И каждый вспомнит удачные и неудачные примеры из своего опыта. Чтобы интервью прошло с пользой для всех его участников, стоит придерживаться набора шаблонов и паттернов. Тогда разговор не пойдет на самотек и собеседование будет успешным.
В статье я расскажу о том, что стоит делать интервьюеру и чего делать не стоит ни в коем случае.
We work using Agile: Scrum, or Kanban, or any other extended project management way. Agile appeared in 2001 as a result of a long discussion between really smart guys. They just formed best practices of management into the shape of short documents - the Agile Manifesto. But what did they want to replace by the Agile way? Most of you may say that they wanted the Waterfall to go to the past. But what would you think if I tell you that the “classical” Waterfall had been a really rare thing even for those days?
Some of the features of your website require message queue integration. It is not a complex task for most developers. If you work with Azure infrastructure, you are able to choose Azure Service Bus as a queue engine. It sounds quite simple: just create Azure Resource, write some code and then be happy! But what would you say if the resources are limited? What will you do if there are several teammates in your team, and all of you have to debug queues at the same time? I try to give you a simple solution.
Стандартный формат сериализации данных в ASP.NET Core Web API - это Camel Case. Но иногда может возникнуть необходимость изменить формат. Казалось бы, нетрудно изменить стратегию сериализации в настройках приложения, однако в процессе я встретил пару подводных камней. В этой статье хочу рассказать вам о том, какие действия нужно предпринять, чтобы можно было полностью изменить формат сериализации данных на Snake Case или любой другой, который вам по душе.
Опыт использования новых маков с М1 начинает расставлять точки над i. Эти чипы быстрые. Очень быстрые. Но почему? В чем магия?
Я смотрел видео на Youtube, где автор купил iMac в прошлом году максимальной конфигурации. Машина с 40+ Gb ОЗУ стоила ему около 4000$. Он смотрел с недоверием, как его гипердорогой iMac был разнесен в пух и прах новеньким Mac mini с М1 на борту, который стоил около 700$.
В реальном мире, тест за тестом, макбуки с М1 не просто превосходят топовые компьютеры Intel прошлых поколений. Компьютеры Mac просто уничтожают их. С недоверием люди стали спрашивать, как такое возможно?
В начале доклада Егор предупреждает, что все, что он расскажет в течение последующих 40 минут, относится к его опыту и к его компании, поэтому необходимо отнестись к его словам с долей скепсиса и иронии. Тем не менее, это его мнение, и он рассказывает "от души". Егор действительно провел около тысячи интервью, но конкретной цифры он не знает. В видео представлены рассуждения о рассчетах цифры, но для конспекта они мало важны.
Когда в твоей команде работают больше одного человека, так или иначе все сталкиваются с проблемой разных стилей кодирования каждого члена команды. Кто-то пишет скобки для блоков if...else, кто-то нет. Когда проект становится больше, то такой код труднее читать и еще сложнее проводить код-ревью.
Чтобы код-ревью и прочие командные митинги не превратились в обсуждение tab vs spaces на повышенных тонах, лучше настроить репозиторий таким образом, чтобы сам проект не допускал написание невалидного и нестандартного для команды кода.
