• Открытая трансляция главного зала DotNext 2018 Piter



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

      Какие доклады попали в открытую трансляцию? Полный список с описаниями — под катом, а перед ним отметим пару вещей. По итогам двух предыдущих DotNext Дилан Битти оказался явным зрительским фаворитом, поэтому откроет DotNext выступлением о том, как работают привычные нам технологии. А буквально вчера, когда доклад уже был полностью готов и согласован, Дилан открыл для себя тонкости кодировки KOI8-R и теперь увлечённо переделывает часть презентации!

      Cменит его в главном зале Андрей Александреску — и это фигура такого масштаба, что мы сами не можем удержаться от селфи с ним. А следующим будет Саша Гольдштейн, которого представлять его дотнетчикам тоже не требуется. В общем, лайн-ап подобрался звёздный.
      Читать дальше →
    • Обзор программы конференции DotNext 2018 Piter



        Конференция: DotNext 2018 Piter
        Дата: 22-23 апреля 2018 года
        Место: Санкт-Петербург, Гостиница «Park Inn by Radisson Пулковская»
        Всего пара дней осталась до следующего DotNext. Над программой и докладами была проведена колоссальная работа — ранее мы уже писали об этом в анонсе конференции и отдельной статье.

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

        Подробное описание программы — под катом.
        Читать дальше →
      • Управляем большим длинным проектом: почему важно разговаривать словами



          У меня в подчинении был один руководитель проектов, который никогда не собирал совещания. Он был немного хикки и обладал исключительным перфекционизмом (насколько это возможно для ПМа), что выражалось в стремлении всё происходящее фиксировать в почте. Письма были очень детальные, на несколько страниц: содержали все нужные описания, в них фиксировались все обещания, сроки, хотелки, большое внимание уделялось договорённостям и упрёкам в безответственности исполнителей. В общем, идеальные письма, последовательно излагающие ход событий, — хоть книгу по ним пиши.

          Но проект шёл медленно: надо же написать письма, потом дождаться ответа и снова написать. Поскольку он был длинным, было ярко заметно, как на третий месяц начали накапливаться задержки и технический долг. Мой коллега продолжал писать письма, фиксируя каждое обязательство и каждый косяк и регулярно перенося сроки. Ситуация накалялась.

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

          Он собрал совещание, но на нём молчал. И все молчали. Точнее, докладывали статусы и поднимали проблемы. Результат совещания — он написал ещё одно длинное письмо с требованиями и фиксацией статусов с косяками.

          Задержки продолжили копиться.
          Читать дальше →
        • Где лучше жить программисту. Сравниваем 9 стран

            Предлагаю вашему вниманию сводную таблицу-сравнение под кодовым названием «Лучшая страна для программиста», которую я подготовила с помощью IT-блогеров из разных стран. В список попали Германия, США, Испания, Канада, Австралия и Австрия, а также добавила в список Англию, Швейцарию и Нидерланды.

            В этой статье страны сравнивались по следующим параметрам:

            1. Зарплаты программистов
            2. Налоги
            3. Стоимость жизни
            4. Социальное обеспечение
            5. Развитость рынка IT
            Читать дальше →
          • Как стать фронтенд-разработчиком в 2018 году

            • Перевод
            Камран Ахмед, автор материала, перевод которого мы сегодня публикуем, говорит, что занимается фуллстек-разработкой уже 5 лет и в настоящее время работает на должности ведущего инженера в компании tajawal. Там ему приходится заниматься многими вещами. Ему, по долгу службы, надо быть в курсе того, что происходит в мире веб-разработки, кроме того, одна из его задач заключается в том, чтобы поддерживать знания и навыки других разработчиков в хорошем состоянии. По его словам, наблюдение за развитием технологий — это не только его работа, но и хобби. Ему приходилось видеть сложности, с которыми сталкиваются начинающие программисты (и опытные — тоже), когда речь заходит об оперативном освоении новшеств. Камрану, в прошлом году, часто приходилось отвечать на вопросы о том, в чём нужно ориентироваться для того, чтобы оставаться современным и востребованным программистом. В результате он, для того, чтобы помочь себе и другим, решил подготовить схемы, ссылки на которые отвечали бы на большинство вопросов, которые ему обычно задают.

            image

            Читать дальше →
          • Применение Теории Ограничений для постановки процесса

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


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


              Алгоритм решения
              • +11
              • 8,1k
              • 4
            • REST API Best Practices

              Привет, Хабр! Представляю вашему вниманию перевод статьи "REST API Best Practices" автора Krishna Srinivasan.

              REST становится общим подходом для представления сервисов окружающему миру. Причина его популярности заключается в его простоте, легкости использования, доступе через HTTP и другие. Существует неправильное представление о том, что все данные, доступные через сеть, считаются REST, но это не так. В этой статье я собираюсь объяснить вам некоторые best practices, которые вы должны всегда помнить при реализации собственного REST приложения. Я бы хотел услышать ваш опыт в REST приложениях, поэтому если вы знаете best practies, которые не упомянуты в этой статье, пожалуйста, поделитесь с нами в комментариях.

              Disclamer: все best practies основаны на моем личном опыте. Если вы имеете другое мнение, не стесняйтесь отправлять его мне на email, и мы обсудим его.

              Здесь представлен список best practices, которые будут обсуждаться в этой статье:

              1. Конечные точки в URL – имя существительное, не глагол
              2. Множественное число
              3. Документация
              4. Версия вашего приложения
              5. Пагинация
              6. Использование SSL
              7. HTTP методы
              8. Эффективное использование кодов ответов HTTP
              Читать далее
            • Почему не работают Уставы и Планы управления проектом?

              Мы приходим к Заказчику и говорим ему: вот так мы будем планировать проект, вот так будем управлять изменениями, вот так будем управлять рисками, вот так будем проводить совещания, вот так будем эскалировать проблемы и принимать решения, вот такие сроки будут у нас на согласование, вот такая периодичность будет статусных совещаний и т.д. И приносим ему это в виде объемного документа этак страниц на 30-50 регламентирующего текста. Заказчик смотрит на это «широко закрытыми глазами» и говорит: «Круто!». То, что не соотносится с практикой, принятой у Заказчика, он предложит исправить, но в остальном документ будет принят.

              А дальше началась жизнь и процессы прошли своим путем, принятия решений своим путем, а документ остался на полке. Иногда РП достает его чтобы показать, что Заказчик не соблюдает установленные сроки, либо нарушает другие договоренности. Но это делается, когда на проекте нарастает напряжение и сторонам нужно защищаться. Есть ситуации, когда РП пытается актуализировать процессы, но часто на него смотрят «косо» как на бюрократа, который вместо результата занимается «бумажками».

              В итоге такой документ выполняет функцию защиты РП-ника или Подрядчика, либо маркетинговую функцию для Подрядчика: «Круто! Вы работаете по проектной технологии!». А хотелось бы, чтобы документ работал.
              Читать дальше →
              • +14
              • 3,8k
              • 7
            • Слои, Луковицы, Гексогоны, Порты и Адаптеры — всё это об одном

              Перевод статьи Mark Seemann о популярных архитектурах разработки ПО и о том, что между ними общего.

              Один из моих читателей спросил меня:
              Вернон, в своей книге «Implementing DDD» много говорит об архитектуре Порты и Адаптеры, как о более продвинутом уровне Слоистой Архитектуры. Хотелось бы услышать ваше мнение на этот счёт.
              Если не вдаваться в детали, то в своей книге я описываю именно этот архитектурный паттерн, хотя никогда не называю его этим именем.

              TL;DR Если применить принцип инверсии зависимостей к слоистой архитектуре, то в конечном счете получим Порты и Адаптеры.
              Читать дальше →
            • Опыт разработки некоммерческого проекта силами джуниоров

                Доброго времени суток, хабрахабр!

                Позвольте рассказать вам небольшую историю, как мы с партнером разрабатывали некоммерческий проект силами джуниоров.

                Эта, для кого-то безумная, идея посетила нас, когда мы поняли, что идей проектов у нас генерируется гораздо больше, чем мы можем реализовать в свободное от основной работы время. Поэтому, мы довольно оптимистично решили, что если взять 2-3х джуниоров, проводить им код-ревью, то мы сможем довольно эффективно реализовать нашу новую идею.

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