Разработка простой мультиплеерной игры с использованием языка программирования dart на сервере и flutter+flame на клиенте. Небольшой гайд от любителя игростроя. Часть 2

Может быть я сейчас залезу немного не на свою территорию и вызову тем самым возмущение определенных специалистов, но есть в этом определенная цель. Может быть я таким образом получу ответ на вопрос: вы кого ищете то с такими интервью? Я не специалист по прохождению и уж тем более по проведению технического интервью, но с точки зрения логики и по косвенным признакам складывается стойкое ощущение, что большинство исполняет их по какой-то дурацкой кальке ничуть не задумываясь о целях и результатах, которые предполагаются.

Смотрите, понятно, что всё зависит от позиции, должности, требований к квалификации. Нет одинаковых интервью, нет одинаковых интервьюеров. Однако цель то всегда одна - найти подходящего специалиста. А не выставить оценку в зачетной книжке, и уж тем более не поблистать собственным умом или самоутвердиться за счет кандидатов.

Опыт прохождения интервью у меня лично небольшой. Как-то так выходило, что меня до сих пор брали сразу. Может везло, может претензий у меня было меньше. Таким образом я не могу говорить за всех. С другой стороны, можно примерно догадываться о том, какие вопросы задают на технических собеседованиях по многочисленным роликам и шпаргалкам. Примерная суть разговоров понятна, и что важнее, она подтвердилась на примере пары известных организации. Более того есть разные статьи на данную тему, есть даже специальные люди, которые не безвозмездно натаскивают кандидатов.

В итоге получается ситуация весьма похожая на выпускные или вступительные экзамены в школе или в вузе. Есть набор типовых, часто совершенно несвязанных с реальностью, вопросов, на которые человеку надо ответить в каком-то диапазоне верных вариантов. А раз есть такой набор, то есть и способы и тактики к ним подготовиться. В общем, если не ходить вокруг да около, типовое техническое интервью отбирает кандидатов, которые специально к этому подготовились.

Построение правильного процесса тестирование очень важно. Это помогает сделать в целом весь процесс разработки более стабильным и предсказуемым, уменьшить нагрузку на тестировщиков, расширить тестируемое покрытие и самое главное уменьшить количество багов на проде. В этой статье хочу рассказать по каким правилам (принципам) мы следовали для построения QA процесса, какой смысл в них вкладывался и как они были реализованы.

Если нет понимания, как измерять качество проекта, значит нет возможности управлять им и обеспечивать качество всего процесса разработки. Чтобы понять, достигается ли заданный уровень и приближается ли команда к цели, используются метрики. С ними должны уметь работать не только лиды и менеджмент, но и QA-специалисты.

В этой статье мы рассмотрим, каким минимальным требованиям должен удовлетворять проект, и определим критерии для настройки сбора метрик. Разберем, что можно измерить на проекте, и как это сделать, чтобы процесс сбора метрик не вызывал негатива, а сами метрики были показательны и действительно помогали принимать управленческие решения.

Рекомендуем материал опытным тестировщикам, тем, кто выполняет роль QA Lead в команде, а также единственным QA на проекте, и всем, кто хочет улучшить качество и производительность процессов тестирования.

Так уж вышло, что в течение своей деятельности мне немало доводилось работать с публичными API, причем как в со стороны, которая их предоставляет, так и со стороны, которая интегрируется. И здесь я хочу рассказать не только про один из кейсов, который решал ранее, но и поделиться результатами проводимого анализа, полученным опытом, а также набитыми шишками.

Материала вышло многовато, поэтому разбил его на 2 части. В части 1 (этой статье) рассмотрим, почему и зачем вообще публичным API нужна документация, есть ли у нее какие-то отличия от документации внутренних API, а также проанализируем и детально разберем различные подходы к ведению такой документации, попутно познакомившись поближе с полезными инструментами.

В следующей части затронем уже непосредственно написание документации, подумаем, кто же должен ее писать, какие инструменты могут в этом помочь, как это встроить в реальный процесс разработки и что во всем этом может пойти не так.

Проблема движения задачи от бизнес-идеи до реализации - не новая, и каждая команда пытается решить её (более или менее успешно) в соответствии со своим опытом и пониманием этой проблемы. Существующие методологии, призванные помогать, зачастую только запутывают. Чтобы срезать острые углы и недопонимания, организуются планирования и груминги (grooming), которые сжигают рабочее время команд и иногда запутывают ещё больше.

Меня зовут Вячеслав. Я разработчик в Сбере.

Главная задача этого руководства - организовать бесшовное и бесконфликтное движение задачи от бизнес-требований до технической реализации. Мы опустим такие важные элементы разработки, как бурные обсуждения и даже груминги, сосредоточив внимание на исполнении специалистами своих обязанностей и передаче задачи дальше, в соответствии её с жизненным циклом. Я исхожу из того, что навыки членов команды соответствуют их ролям, и что все выполняют свои задачи на приемлемом уровне.

Привет, Хабр!

На связи участник профессионального сообщества NTA Максим Алёшин.

Сегодня создание интерактивной карты на python не составляет большого труда: стоит подключить библиотеку (например, Folium или Bokeh), указать картографический сервер, и после выполнения нескольких «магических» строк кода ваши данные как на ладони!

Но что делать, если данные есть, визуализировать их хочется, а в сети, в которой вы работаете, нет доступа к картографическим серверам? В этом случае помогут Plotly и GeoPandas. Но придётся провести ряд подготовительных работ. В этом посте шаг за шагом я покажу, как построить интерактивную карту России по регионам с помощью Plotly, которая будет работать без интернета, регистрации и смс.

Всем привет! Меня зовут Нурислам (aka tonitaga), и сегодня я бы вам хотел рассказать об Базовых алгоритмах на графах.

Всем привет! Представим, что вам нужен доступ к данным каких-либо смарт-контрактов на Ethereum (или Polygon, BSC и т.д.), например, Uniswap, SushiSwap, AAVE (или даже PEPE-coin) в реальном времени, чтобы анализировать их с помощью стандартных инструментов дата-аналитиков: Python, Pandas, Matplotlib и т.д. В этом туториале я покажу инструменты для доступа к данным на блокчейне, которые больше похожи на хирургический скальпель (сабграфы The Graph), чем на швейцарский нож (доступ к RPC ноде) или, скажем, молоток (готовые API от компаний-разработчиков). Надеюсь, мои неумелые метафоры вас не пугают. Кому интересно научиться, добро пожаловать под кат.

Всем привет! Я Александр Яковлев, в Тинькофф руковожу разработкой бизнес-линии в нефинансовых сервисах.

Расскажу, чем занимаются тимлиды у нас в компании и что делать, чтобы вырасти до тимлида, а еще пройдусь по распространенным заблуждениям о работе. Добро пожаловать под кат!

Поднимите руки те, у кого есть номер телефона... Вау, лес рук! Но знаете ли вы, что скрывается за этим набором цифр?

Говорят, у менеджеров никогда нет времени - у них постоянные созвоны и миллион разных дел. Свободный слот в их расписании найти сложнее, чем билеты на концерт твоей любимой группы. Создаётся впечатление, что чем выше твоя должность, тем больше времени в сутках тебе нужно, чтобы всё успевать. И начинает казаться, что помочь тут может только маховик времени из мира волшебства. Так вот, это не так. Если к вашему тимлиду нужно записываться за 2 недели, или вы сами менеджер, и у вас постоянно не хватает ни на что времени, то знайте - это не норма.

Чаще всего мы просто не умеем управлять своим временем. Пытаемся быть везде, делать всё. Но через какое-то время должно прийти понимание простого факта - невозможно решать проблему нехватки времени простым масштабированием рабочих часов. В такой тупик часто упираются менеджеры-новички, но к некоторым понимание, как быть более эффективным, не приходит ещё очень долго. У новоиспеченного тимлида может сформироваться ощущение, что он обязан обрабатывать весь поток входящей информации и как-то на него реагировать, - помогать, решать их проблемы и т.п., т.е. тратить на все это время. Ведь он теперь тимлид, на нем всё держится! И вообще, хочется показать коллегам, что не зазнался и не превратился в небожителя, который теперь игнорирует все проблемы “простых смертных”, а наоборот всё ещё бывший коллега-разработчик, весь в доску свой и небезразличный. Но с такой загруженностью у него просто не остается времени на высокоуровневый взгляд на работу, при котором видны проблемы всего проекта. Когда же планировать стратегические - кадровые, архитектурные и коммуникационные - решения?

У начинающих тимлидов пухнет голова от того, что им нужно делать. И тут легко не заметить, что более важный вопрос - чего, наоборот, делать не следует. В этой статье разберем, как выявить подобные вещи, почему за них не стоит браться и куда их девать.

В быстроменяющемся мире разработки программного обеспечения перестать самосовершенствоваться – значит встать на путь деградации. Технологии настолько быстро меняются, так что те, кто способен сохранять темп и учиться новому – получают все сливки, а кто не успевает, будут терять свою конкурентоспособность, и как следствие доходы. В этой статье я хочу рассказать об основных моментах, на которых можно прогореть на пути к профессиональному совершенствованию, а также о том, как этого можно избежать.

Кому будет полезна статья?

Middle и junior продактам — позволит найти свои зоны роста, а также подготовиться к собеседованиям в топовые IT компании.

Тем, кто хочет стать менеджером продукта, но не знает какие компетенции стоит прокачать, чтобы войти в профессию.

Нанимающим менеджерам — поможет составить требования к вакансии продакта и провести интервью.

Проведём небольшой ликбез по работе телефонной коммутации. Полученные знания помогут освоить настройку автоматических телефонных станций (АТС).