• Сложность должна обитать где-то

    • Перевод

    Борьба со сложностью является постоянной темой в области создания программного обеспечения, которое я встречаю снова и снова. Это нечто, что я постоянно вижу в обсуждениях на всех уровнях, ну например, как много комментариев должно сопровождать методы и функции? Каково идеальное "количество" абстракции? Когда фреймворк начинает содержать "слишком много магии"? Когда в компании используется слишком много языков программирования?


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

    Продолжение ...
  • История архитектуры Dodo IS: путь бэкофиса

      Хабр меняет мир. Больше года мы ведём свой блог. Где-то полгода назад нам прилетел вполне логичный фидбэк от хабровчан: «Додо, вот вы везде говорите, что у вас своя система. А что это за система? И зачем она нужна сети пиццерий?».

      Мы посидели, подумали и поняли, что вы правы. Мы пробуем объяснить всё на пальцах, но выходит рваными кусками и нигде нет полноценного описания системы. Так начался долгий путь сбора информации, поиска авторов и написания серии статей про Dodo IS. Погнали!
      Благодарности: спасибо, что делитесь своим фидбэком с нами. Благодаря ему мы наконец описали систему, составили технорадар и скоро выкатим большое описание наших процессов. Без вас так бы и сидели ещё 5 лет.

      Читать дальше →
    • Идеальный бэклог продукта

      • Перевод
      И снова здравствуйте. Перевод данной статьи был подготовлен в преддверии старта курса «Agile Project Manager в IT».




      Здоровый бэклог продукта является необходимым условием для успешной Scrum-команды. Вместо того, чтобы сосредотачиваться только на доработке пользовательских историй для предстоящего спринта, предусмотрительные Scrum-команды инвестируют в доработку бэклога продукта, чтобы повысить прозрачность, сосредоточиться на своем видении и сохранить согласованность действий. Прозрачность – это гораздо больше, чем просто предоставление информации, заинтересованная сторона должна иметь возможность получить искомую информацию в течение нескольких секунд.
      Читать дальше →
    • Асинхронный код в Startup ASP.NET Core: 4 способа обхода GetAwaiter().GetResult()

        С тех пор, как в C# 5.0 завезли механизм async/await, нас постоянно во всех статьях и доках учат, что использовать асинхронный код в синхронном очень плохо. И призывают бояться как огня конструкции GetAwaiter().GetResult(). Однако есть один случай, когда сами программисты Microsoft не гнушаются этой конструкцией.


        Читать дальше →
      • Кроссплатформенная разработка мобильных приложений в 2020 году

        Всем привет!

        Я – Сергей Якимов, CTO Omega-R, международной компании по разработке и интеграции IT-решений. На базе многолетнего опыта в сфере информационных технологий и экспертизы компании хочу поделиться своим видением настоящего и ближайшего будущего кроссплатформенной разработки мобильных приложений.

        image
        Читать дальше →
      • Сравнение производительности инструментов обхода блокировок\VPN

        По мере того, как нам все активнее закрывают доступ к различным ресурсам в сети, все актуальнее становится вопрос обхода блокировок, а значит все актуальнее становится вопрос «А как же быстрее обходить блокировки?».

        Оставим тему эффективности, с точки зрения обхода DPI\вайтлистов\блеклистов для другого случая, и просто сравним производительность популярных инструментов обхода блокировок.

        Внимание: В статье под спойлерами будет много картинок.
        Читать дальше →
      • Если вы что-то создаёте, избегайте расписания менеджера

        • Перевод


        В книге ”Masters of Doom” о компании id Software и её влиянии на массовую культуру Дэвид Кушнер размышлял о необычном стиле работы ведущего программиста Джона Кармака.

        Чтобы повысить производительность и не отвлекаться от работы над движком Quake, тот принял агрессивный подход — начал постепенно смещать начало рабочего дня. В конце концов Джон садился программировать вечером, а заканчивал перед рассветом. Эти непрерывные отрезки тишины, изоляции и глубокой работы позволили ему создать первый в мире сверхбыстрый 3D-движок. Игра Quake произвела настоящий фурор.
        Читать дальше →
      • Перестаньте заниматься не своей работой

          Вы легко отзываетесь на просьбу помочь? Вам не трудно сделать пару лишних задач? Вы молча переделываете не очень хорошую работу за коллегами или подчинёнными? Скорее всего, ваша рабочая нагрузка заставляет вас «перегреваться». 

          Нередко в малом бизнесе мы занимаемся всем подряд, не замечая того: тестовый сервер будет перезапущен, о чём мы сами и сообщим в чате клиенту вместо инженера; баннер повесить — да погоди, у меня есть доступ к админке, готово; код аналитики — да давай я тебе Tag Manager повешу и покажу, как через него любые теги размещать; вот тут в выгрузке были подозрительные пики и провалы, я тебе сделал дополнительную детализацию… Особенно тяжело ситуация обстоит в компаниях, которые активно работают по заявкам клиентов, и каждый сотрудник берёт в работу самые разноплановые задачи. Как итог: усталость, выгорание, ошибки и завалы собственных невыполненных задач. Знакомо? Давайте искать причины и выходы под катом.

          Читать дальше →
        • Автоматизация End-2-End тестирования комплексной информационной системы. Часть 1. Организационная

            Этой статьей мы открываем серию публикаций о том, как автоматизировали в одном из крупных проектов компании ЛАНИТ процесс ручного тестирования большой информационной системы и что у нас из этого вышло.

            Первая часть – организационно-управленческая – должна быть полезна в первую очередь тем, кто отвечает за автоматизацию тестирования и создает такие системы в целом. Руководители проектов, лидеры групп и владельцы сервисов функционального и автоматического тестирования, все, кого волнует вопрос «как построить экономически эффективное end-2-end тестирование своей ИТ системы», найдут здесь конкретный план и методику.

            Источник
            Читать дальше →
          • [в закладки] PDF- и ePUB-версия руководства по React

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



              Для новых читателей нашего блога — два бонуса внутри.
              Читать дальше →
              • +52
              • 20,9k
              • 9
            • Управление распределенной командой в режиме многопроектности (обзор и видео доклада)



                23-24 сентября в Санкт-Петербурге проходила конференция Saint TeamLead Conf 2019. «Флант» принял в ней активное участие: Игорь Цупко (наш директор по неизвестному) провел митап, на котором участники разобрались в способах поиска и выявления тайных знаний внутри организации, а Сергей Гончарук (менеджер проектов) выступил с докладом «Управление распределенной командой в режиме многопроектности». По традиции, мы публикуем обзор доклада и его видео (~37 минут).
                Читать дальше →
              • Stand-up, Scrum, Daily meetings — что это и для чего

                image

                Часто стал замечать, что люди все больше и больше перетягивают методологии и практики из IT сферы в производственные, банковские, сферы услуг и прочие. Одной из самых распространенных «заимствованных» из мира IT практик является проведение Scrum, Daily, Stand-up митингов ( как их только не называют, но везде суть примерно одинаковая). Ниже будет представлено описание этого процесса таким образом, как его провожу лично я.

                Общее


                Данный пост описывает цель и регламент проведения ежедневного митинга — Стендапа. Основа данного процесса была взята из scrum методологии и является частью процесса разработки, в будущем может быть адаптирована под текущую команду, а так же и процесс разработки. Как и любой инструмент использование и отношение к нему будут определять результаты.

                Цель


                • подготовка к рабочему дню и планирование его;
                • оценка предыдущего своего рабочего дня;
                • поделиться информацией и планами с коллегами;
                • получить информацию от коллег, которая может пригодится в течение рабочего дня.
                Читать дальше →
              • Sprint Review: Днище — Огнище

                  «Мы легли на дно, мы зажгли огни, во Вселенной только мы одни». Кажется, эту строчку из песни группы Сплин смело можно признать саундреком внедрения практики Sprint Review у нас в Dodo Pizza.


                  Читать дальше →
                • Визуальное программирование — почему это плохая идея

                  • Перевод
                  image

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

                  Язык визуального программирования — это такой язык, который позволяет программисту создавать программы, манипулируя графическими элементами, а не печатая текстовые команды. Известным примером является Scratch, язык визуального программирования родом из MIT, который используется для обучения детей. Его преимущества заключаются в том, что он делает программирование более доступным для новичков и не-программистов.

                  В 1990-х годах было очень популярное движение по внедрению визуального программирования в корпоративную среду с помощью так называемых CASE-инструментов, где корпоративные системы можно было бы определять с помощью UML и генерировать [их код] без необходимости в привлечении обученных разработчиков программного обеспечения. Это связано с концепцией «round tripping» («туда и обратно»), где система может быть смоделирована визуально, программный код будет генерироваться из полученных моделей, а любые изменения кода могут быть возвращены обратно в модель. Увы, подобные инструменты так и не смогли выполнить свою миссию, и большинство из экспериментов [по их внедрению] в настоящее время в значительной степени заброшены.
                  Читать дальше →
                • Сопротивления автоматизации тестирования

                  Несмотря на то, что технологии модульного тестирования существуют уже 30 лет (в 1989 году Кент Бек написал статью “Simple Smalltalk Testing: With Patterns”), тем не менее не все программисты владеют этой технологией и не все компании сделали автоматическое тестирование частью своей корпоративной культуры. Даже несмотря на очевидные преимущества автоматического тестирования, все равно поведенческое сопротивление достаточно сильное. Кто пробовал внедрять автоматические тесты, тот знает, что всегда найдется какая-то причина, почему это не удалось сделать.


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


                  Все возражения я сгруппировал в пирамиду надежного программирования, которая включает четыре уровня:

                  Читать дальше →
                • Definition of Ready — то, о чем нам забыли рассказать

                  Введение
                  Что такое DoR
                  Зачем нужен DoR
                  Где применять DoR
                  Когда применять DoR
                  INVEST модель
                  Заключение
                  Список литературы




                  Введение


                  Наверняка вы не раз слышали, скорее даже использовали с командой артефакт Scrum — Definition of Done далее по тексту — DoD. Возможно, используете его, даже не осознавая этого. О DoD написано много русскоязычных статей. О нём говорят на конференциях, и тренингах. Разобраться для чего нужен этот артефакт, и найти примеры не трудно. DoD определяет критерии, по которой каждый член команды понимает, что задача закрыта. Глубинная цель — синхронизировать понятие Done, между каждым членом команды. Над этими критериями, часто, команда трудится во время ретроспективы. Существует похожий артефакт, о котором почему-то нет упоминания в русскоязычных ресурсах о Scrum, а там где этот артефакт упоминается, не даётся никаких разъяснений что это, зачем нужен, и как использовать.


                  Скорее всего, в вашей команде звучали фразы наподобие: «Мы завалили цель, потому что неправильно оценили задачу», или «Наш PO опять пришёл с задачей без должного описания». В моей команде, подобные “сигналы” появлялись не один раз, и я долго искал способ, чтобы решить эту проблему.

                  Читать дальше →
                  • +18
                  • 31,3k
                  • 5
                • Лечение «механического» Scrum. Часть 3. Работа SM

                    Как следует из названия, это продолжение серии статей про роли в scrum (часть 1 и часть 2). Сегодня рассмотрим следующую роль – scrum master. Как это ни парадоксально, успешность scrum во многом зависит от scrum мастера. Поэтому хочется снова призвать силу воображения и привести метафору (дисклеймер: пример никоим образом не должен оскорбить чьих-либо чувств). Есть культура, у которой есть свой культ, свои обряды, есть служители этого культа. Служителей можно разделить на различные классы:

                    • те, кто со своей культурой предпочитают быть один на один — отшельники, затворники, просветленные;
                    • те, кто выучили все правила, нашли лазейки, понимают, что и как делать, и используют культ в корыстных целях, наживаясь на людях, их страхах и предубеждениях;
                    • фанатики, которые пытаются насадить свою культуру к месту и не к месту. Для которых кроме их знаний, всё остальное ересь;
                    • те, кто искренне верит, чувствует и пытается поделиться, помочь и подарить это чудо людям; они рассказывают и объясняют, слушают и пытаются помочь.

                    Со Scrum и SM-ами, мне кажется, происходит очень похожая история. Попробуйте посмотреть на знакомых вам SM через такую призму. С какими SM вам бы хотелось работать?
                    image
                    Давайте разберемся, какие тревожные симптомы могут быть у SM.
                    Читать дальше →
                  • Лечение «механического» Scrum. Часть 1. Работа PO

                      Я больше 10 лет работаю с / в / для agile в сфере web-разработки. Из них больше всего пришлось иметь дело с самым популярным agile фреймворком — scrum (по данным VersionOne). Хочу поделиться с вами накопленными наблюдениями и выводами.


                      Начну с метафоры, так как иногда приходилось видеть внедрение scrum по такому сценарию:


                      • До scrum: «разработка» как младенец — она целеустремленна, но не умеет нормально ходить, а очень хочет научиться, чтобы добираться до цели.
                      • Внедрение: приходит учитель (scrum тренинги, курсы, agile coach и т.п.) и показывает, как ходить. Малыш счастлив, он двигается шагами! Топ-топ-топ. У нас спринты — мы ходим!
                      • После внедрения: терпеливые стейкхолдеры говорят: «Окей, погнали к цели», на что получают «не давите на команду, мы ходим!». Разработка выписывает интересные траектории и получает удовольствие от процесса, но цель забыта.
                      • Scrum-но: дальше пилюля правды от бизнеса, scrum «мутирует» и позволяет бизнесу получать какой-никакой продукт от разработки. И, к сожалению, формально ставится галочка «мы работаем по scrum», а реальный потенциал команды разработки так и не раскрыт, да и кругом говорят «scrum ненастоящий».


                      Читать дальше →
                    • IDisposable — что ваша мама не говорила об освобождении ресурсов. Часть 1

                      • Перевод

                      Это перевод первой части статьи. Статья была написана в 2008 году. Спустя 10 лет почти не потеряла актуальности.


                      Детерминированное освобождение ресурсов — необходимость


                      В течение более чем 20-летнего опыта кодирования я иногда разрабатывал собственные языки для решения задач. Они варьировались от простых имеративных языков до специализрованных регулярных выражений для деревьев. При создании языков есть множество рекомендаций и некоторые простые правила не должны нарушаться. Одно из них:


                      Никогда не создавай язык с исключениями, в котором нет детерминированного освобождения ресурсов.

                      Угадайте какой рекомендации не следует рантайм .NET, и как следствие все языки на его базе?

                      Читать дальше →
                    • Особенности разработки API: какой API является хорошим?

                        Наверное, абсолютно все читатели используют API, работая с фрэймворками, библиотеками, виджетами, как некий язык общения между сущностью и основным приложением. И вы наверняка замечали, что некоторыми API удобнее пользоваться, а в некоторых есть явные проблемы. Всеволод Шмыров (@vsesh) в своем докладе на Frontend Conf, расшифровку которого вы найдете под катом, постарался ответить на вопрос, какой API является хорошим.

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

                        image

                        Однако, в докладе не будет ответа на вопрос, нужен ли вам свой API. Надеемся, после прочтения вы взвесите все «за» и «против» и сами поймете, нужен ли он вам. Всеволод просто расскажет, с какими сложностями приходится сталкиваться разработчикам API, какие проблемы решать и что еще делать, а именно про эти четыре важных пункта:


                        Читать дальше →