Привет! Меня зовут Катя, я заместитель руководителя направления системного анализа в Контуре, а еще программный директор Конференции аналитиков.
Уже 6 лет каждый август проходит Конференция аналитиков Контура. Она начиналась как внутренний ивент для функциональной зоны, а затем трансформировалась в большое мероприятие для наших внешних коллег!
В статье расскажем, как мы готовились (готовимся до сих пор!) и что вас ждёт!
Использование DI-контейнеров часто приводит к появлению неприятных ошибок в рантайме. В таких случаях хочется, чтобы контейнер умел находить проблемы и уведомлять о них в момент сборки.
С проверкой регистраций, добавленных через рефлексию, все довольно просто, и некоторые контейнеры даже предоставляют такой функционал из коробки. Но вот что делать с регистрациями-делегатами сходу неясно и даже может показаться, что от ошибок резолва сервисов внутри делегатов никуда не деться.
В статье на примере Autofac посмотрим, как устроены регистрации-делегаты, и научимся находить в них ошибки до того, как контейнер начнет использоваться приложением. По ходу дела вспомним, как работают замыкания в C# и как размещаются в памяти анонимные делегаты, а также рассмотрим способ анализа MSIL-инструкций в процессе выполнения программы.
Привет! Это Маша и Серёжа, в прошлом тексте мы научились анализировать связи между двумя качественными переменными, а сегодня расскажем, как анализировать линейную зависимость между двумя количественными.
Привет! Меня зовут Ксюша, я работаю бэкенд-разработчиком на C# в Контуре. В весеннем семестре я провела курс по функциональному программированию на Haskell для студентов 3 и 4 курса направления ФИИТ (фундаментальная информатика и информационные технологии) в УрФУ и хочу поделиться своим опытом организации и проведения курса.
Привет! Меня зовут Ксюша Бердникова, я исследователь в Контур.Удостоверяющий Центр. Меня очень вдохновляет наставничество и системный подход к нему, поэтому в статье хочу обсудить: какие шаги, привычки и приемы помогают выстроить эффективную систему наставничества и как наставнику сохранять фокус на своих задачах, не теряя баланс.
Привет! На связи Серёжа и Маша, и это третья часть в нашей серии обучений по статистике. В прошлых статьях мы разобрали, как оценить среднюю удовлетворенность пользователей и как её сравнить. Сегодня мы научимся анализировать взаимосвязь качественных переменных между собой.
Как-то было свободных полчаса перед встречей. Ни туда, ни сюда. Дай, думаю, сниму трейс с приложения. Вдруг что-то интересное найдётся.
А в качестве бонуса: использование var может привести к багам? Узнаем в самом конце ;)
Бывает, что в команде начинает что-то идти не так: увеличивается количество факапов, разработчики начинают увольняться, задачи делаются месяцами годами. Часть этих проблем может уходить корнями в накопленный техдолг.
В этой статье я хочу поделиться опытом организации работы по устранению техдолга в нескольких командах, в которых я побывал за 7 лет своей работы в Контуре. Продукты были разные: от стартапа и бурно развивающегося гиганта, до сервиса, переживающего не лучшие времена.
Каждый раз приходя в новую команду, я находился в растерянности и не понимал, за что бы взяться, чтобы начать менять удручающую ситуацию с техдолгом. Поэтому я решил собрать свои подходы в понятный план действий, который, конечно же, неидеален, но точно поможет вам начать работать с проблемами.
Сравнивая различный code-style в проектах, я упоминал про методы проверки коллекций на наличие элементов. Самые очевидные способы – это использование LINQ-метода Any() или сравнение свойства Count с нулем. И если вы выбрали первый вариант, то у вас могут быть проблемы. Поэтому предлагаю подробнее рассмотреть этот вопрос. Кстати, если вы выбрали второй вариант, то у вас тоже могут быть проблемы.
Привет! На связи Серёжа и Маша, а это — второй текст в нашей серии обучений по статистике. В прошлый раз мы научились оценивать среднее и строить доверительные интервалы. Сегодня же мы научимся сравнивать несколько выборок между собой.
Заморозка проекта — редкая, но непростая задача для менеджера. В подобных задачах не всегда бывают готовые решения, как экологично пройти через все этапы процесса. Я расскажу, как мы с командой прошли через заморозку, и поделюсь несколькими советами, как поддержать демотивированную команду и, конечно же, не забыть про себя. Все выводы в этой статье проверены на моем собственном опыте.
Когда я вижу очередную статью или видеоурок про тестирование кода, я почти уверен, что мне опять расскажут про моки.
Создаётся впечатление, что это самый лучший и правильный способ писать тесты, и вообще, невозможно обойтись без моков. Это не так! Можно писать тестируемый код без моков. Более того, использование моков следует избегать и использовать их только в специфичных случаях.
Привет! Я Ната из Контур.Эльбы. Мы делаем сервис, с которым предприниматель может вести бизнес без бухгалтера и не бояться каждого письма от ФНС. Недавно я писала о выборе между наймом, самозанятостью и ИП — и в комментах мне подсказали тему следующей статьи: патент для IT-специалистов.
Что ж, разбираемся, что такое патент — и когда айтишнику стоит рассмотреть всерьез эту систему налогообложения.
Представьте: две компании объединились, и вы оказались тем, кому придется приспосабливаться под новые реалии. Новым тут может быть абсолютно все: корпоративный стиль и этика, рабочие процессы, инструменты, карьерные возможности.
У меня есть 5 рекомендаций, которые помогут наименее болезненно это пережить.
Сложная и тяжелая статья с непропорционально простым выводом. Вспомним фон Неймана, затронем процессорный кеш, поговорим про регистры и компиляторы. Тем, кому не хочется погружаться в детали, достаточно прочитать только Введение и Выводы.
Привет! Меня зовут Катя Халитова, я исследователь из Контур.Фокуса. Cегодня поговорим про важное для бизнеса взаимодействие исследователей и продакт-менеджеров. Эта статья основана на десяти экспертных интервью со специалистами из ритейла, финтеха, телекома и других сфер.
Мы затронем следующие вопросы:
– Как распределяется зона ответственности в discovery между продактом и исследователем? Есть ли чёткие рамки?
– Какие ожидания есть у продактов и исследователей друг от друга?
– Должен ли продакт валидировать исследования, когда проводит их самостоятельно?
– Какие факторы влияют на внедрение результатов исследования?
Каждое приложение пишет множество метрик: системных (потребление CPU, памяти, очереди на диск) и прикладных (количество операций, время их выполнения, коды ошибок). Это полезная информация для отслеживания состояния сервисов в моменте и динамики за период. А что если сделать из этого продукт, который полезен для пользователей?
Привет! Мы UX-исследователи из Контура Серёжа и Маша. Этот текст — первый в серии о методах статистического анализа.
Представьте себе ситуацию: вы замерили удовлетворенность пользователей и получили среднюю оценку в 6.5 баллов из 10. Затем вы упорно и долго работали всей командой над тем, чтобы эту оценку повысить. Через полгода вы с надеждой повторяете опрос и получаете… 6 баллов. Бизнес-начальник врывается к вам в кабинет и начинает ругаться: «Как же так?! Весь год работали, а удовлетворенность упала!».
А точно ли она упала? Точно ли это изменение связано с тем, что пользователи меньше довольны нашим продуктом, а не с тем, что во второй раз в нашу выборку попали менее довольные пользователи? На эти и похожие вопросы нам помогает ответить статистика.
В каждой команде разработки есть сотрудники, чьи знания и опыт критически важны для стабильной работы над продуктом. Когда такой человек принимает решение покинуть команду, команда сталкивается с серьезным вызовом: как сохранить его экспертизу и обеспечить непрерывность работы.
В апреле я съездил на HolyJS. Еще до поездки в расписании конференции моё внимание привлек доклад Виктора Хомякова «Удаление мертвого кода в проекте: практическое руководство». Послушав его, я понял, что могу использовать полученные знания в своем текущем проекте, при этом не затрачивая много усилий. В этой статье я расскажу, что у меня получилось.
