День 2073. #ЗаметкиНаПолях
Реалистичные Фейковые Данные с Помощью Bogus. Окончание
Начало
Продолжение
Заполнение БД в памяти фиктивными данными
Используем Entity Framework для БД в памяти. Для этого нужно установить NuGet-пакет Microsoft.EntityFrameworkCore.InMemory.
Теперь добавим класс DbContext и зададим БД в памяти:
Теперь можно заполнить БД данными, сгенерированными Bogus, переопределив метод OnModelCreating:
Здесь мы используем метод GenerateBooks, описанный во вчерашнем посте, и задаём полученный список книг в качестве содержимого набора данных Books.
Теперь можно прочитать данные из нашей БД:
Изучите все потенциальные возможности Bogus здесь. Это поможет сделать ваши тесты и эксперименты осмысленными и более понятными.
Итого
Bogus — отличная библиотека для создания модульных и интеграционных тестов. Генерировать фиктивные данные может быть полезно и в других различных сценариях, например, для создания заглушки сервиса, заполнения пользовательского интерфейса реалистичными данными или опробования других инструментов и функций.
Источник: https://www.code4it.dev/blog/seed-inmemory-entityframework-bogus/
Реалистичные Фейковые Данные с Помощью Bogus. Окончание
Начало
Продолжение
Заполнение БД в памяти фиктивными данными
Используем Entity Framework для БД в памяти. Для этого нужно установить NuGet-пакет Microsoft.EntityFrameworkCore.InMemory.
Теперь добавим класс DbContext и зададим БД в памяти:
public class BooksDbContext : DbContext
{
public DbSet<Book> Books { get; set; }
protected override void
OnConfiguring(DbContextOptionsBuilder builder)
{
builder.UseInMemoryDatabase("BooksDatabase");
}
}
Теперь можно заполнить БД данными, сгенерированными Bogus, переопределив метод OnModelCreating:
protected override void
OnModelCreating(ModelBuilder mb)
{
base.OnModelCreating(mb);
var books =
BogusBookGenerator.GenerateBooks(15);
mb.Entity<Book>().HasData(books);
}
Здесь мы используем метод GenerateBooks, описанный во вчерашнем посте, и задаём полученный список книг в качестве содержимого набора данных Books.
Теперь можно прочитать данные из нашей БД:
using var ctx = new BooksDbContext();
ctx.Database.EnsureCreated();
var allBooks = await ctx.Books.ToListAsync();
var thrillers = ctx.Books
.Where(b => b.Genres.Contains(Genre.Thriller))
.ToList();
Изучите все потенциальные возможности Bogus здесь. Это поможет сделать ваши тесты и эксперименты осмысленными и более понятными.
Итого
Bogus — отличная библиотека для создания модульных и интеграционных тестов. Генерировать фиктивные данные может быть полезно и в других различных сценариях, например, для создания заглушки сервиса, заполнения пользовательского интерфейса реалистичными данными или опробования других инструментов и функций.
Источник: https://www.code4it.dev/blog/seed-inmemory-entityframework-bogus/
👍14
День 2074. #Карьера
Упрощатели Заходят Далеко, Усложнятели Застревают
«Если вы не можете объяснить это шестилетнему ребенку, вы сами этого не понимаете».
– Альберт Эйнштейн
В бизнесе есть два типа людей:
1. Упрощатели - делают сложные вещи простыми.
2. Усложнятели - делают простые вещи сложными.
Короткая шутка
- Как усложнятель называет упрощателя?
- Босс.
Где-то, когда-то некоторые люди решили, что в бизнесе нужно все усложнять и говорить на деловом жаргоне.
«Что ж, это интересное предложение, и я не обязательно против него, поэтому позвольте мне поднять его на флагшток, чтобы мы могли побить его палками, как пиньяту. Поскольку я слышал, что эта идея имеет некоторую поддержку в этой области, позвольте мне связаться с ребятами наверху, и мы посмотрим, хватит ли у нас ресурсов, чтобы продолжить работу над этим. Если стоимость выше $100 тыс., мне, возможно, придётся отложить эту идею, потому что нам нужно сохранить немного сухого пороха в ожидании результатов стратегической встречи — где, как я знаю, мы рассматриваем серьёзные изменения. Так что давайте оставаться на связи. Честь и хвала команде за то, что они придумали такое отличное ценностное предложение, но сейчас, боюсь, не могу его принять.»
Это один из способов спрятаться за сложностью: сделать себя совершенно непонятным. Хотя это может произвести впечатление на кого-то, ваши подчинённые будут высмеивать вас, а ваши начальники захотят поговорить с кем-то другим. При общении с руководителями нужно говорить чётко и, прежде всего, отвечать на вопросы. В большинстве организаций, хотя жаргон и двусмысленность могут быть распространены среди менеджеров среднего звена, они почти отсутствуют среди руководителей.
Другой способ спрятаться за сложностью — не лингвистический, а концептуальный: всегда находить проблему вышестоящего уровня или более масштабную проблему, которая будет блокировать прогресс на нижнем уровне. Рассмотрим такое утверждение:
«Я хотел бы перейти на новый процесс, но мы ещё не завершили обучение.»
Является ли это веской причиной для отсутствия прогресса в переходе на новый процесс или это пассивное сопротивление, замаскированное под причину? Например, я не хочу переходить на новый процесс, поэтому у меня постоянно «возникают проблемы» с планированием обучения. Или это добросовестное усложнение? Если обучение можно свести к одной странице, которую каждый может прочитать за 5 минут, то просто сократите его.
Есть старая поговорка:
«Когда вы спрашиваете время, некоторые люди скажут вам, как собрать часы. Другие расскажут вам, как построить целую швейцарскую деревню.»
Тест на выявление усложнятелей — это поиск следующих паттернов поведения:
- Медленный прогресс в достижении результатов
- Ссылки на сложность или запутанность
- Тенденция находить искусственные предварительные условия и осложнения, которые кажутся правдоподобными, но при дальнейшем рассмотрении таковыми не являются.
Вещи настолько сложны, насколько мы хотим их сделать. В большинстве случаев сложность — это оправдание либо нежелания что-то делать, либо незнания, как что-то делать.
Стремитесь делать вещи простыми. Стремитесь понять их. Боритесь за то, чтобы найти для них подходящие метафоры. Если вы не тратите энергию, пытаясь упростить вещи для своей аудитории, вы больше всего похожи на усложнятеля. Если так, то в следующий раз, когда вы соберётесь объяснить кому-то, почему что-то занимает так много времени, является таким сложным или требует выполнения 5 шагов перед началом, спросите себя: «Действительно ли я в это верю или я все усложняю, потому что либо не хочу, либо не знаю, как это сделать?»
Источник: https://kellblog.com/2015/05/13/career-advice-simplifiers-go-far-complexifiers-get-stuck/
Упрощатели Заходят Далеко, Усложнятели Застревают
«Если вы не можете объяснить это шестилетнему ребенку, вы сами этого не понимаете».
– Альберт Эйнштейн
В бизнесе есть два типа людей:
1. Упрощатели - делают сложные вещи простыми.
2. Усложнятели - делают простые вещи сложными.
Короткая шутка
- Как усложнятель называет упрощателя?
- Босс.
Где-то, когда-то некоторые люди решили, что в бизнесе нужно все усложнять и говорить на деловом жаргоне.
«Что ж, это интересное предложение, и я не обязательно против него, поэтому позвольте мне поднять его на флагшток, чтобы мы могли побить его палками, как пиньяту. Поскольку я слышал, что эта идея имеет некоторую поддержку в этой области, позвольте мне связаться с ребятами наверху, и мы посмотрим, хватит ли у нас ресурсов, чтобы продолжить работу над этим. Если стоимость выше $100 тыс., мне, возможно, придётся отложить эту идею, потому что нам нужно сохранить немного сухого пороха в ожидании результатов стратегической встречи — где, как я знаю, мы рассматриваем серьёзные изменения. Так что давайте оставаться на связи. Честь и хвала команде за то, что они придумали такое отличное ценностное предложение, но сейчас, боюсь, не могу его принять.»
Это один из способов спрятаться за сложностью: сделать себя совершенно непонятным. Хотя это может произвести впечатление на кого-то, ваши подчинённые будут высмеивать вас, а ваши начальники захотят поговорить с кем-то другим. При общении с руководителями нужно говорить чётко и, прежде всего, отвечать на вопросы. В большинстве организаций, хотя жаргон и двусмысленность могут быть распространены среди менеджеров среднего звена, они почти отсутствуют среди руководителей.
Другой способ спрятаться за сложностью — не лингвистический, а концептуальный: всегда находить проблему вышестоящего уровня или более масштабную проблему, которая будет блокировать прогресс на нижнем уровне. Рассмотрим такое утверждение:
«Я хотел бы перейти на новый процесс, но мы ещё не завершили обучение.»
Является ли это веской причиной для отсутствия прогресса в переходе на новый процесс или это пассивное сопротивление, замаскированное под причину? Например, я не хочу переходить на новый процесс, поэтому у меня постоянно «возникают проблемы» с планированием обучения. Или это добросовестное усложнение? Если обучение можно свести к одной странице, которую каждый может прочитать за 5 минут, то просто сократите его.
Есть старая поговорка:
«Когда вы спрашиваете время, некоторые люди скажут вам, как собрать часы. Другие расскажут вам, как построить целую швейцарскую деревню.»
Тест на выявление усложнятелей — это поиск следующих паттернов поведения:
- Медленный прогресс в достижении результатов
- Ссылки на сложность или запутанность
- Тенденция находить искусственные предварительные условия и осложнения, которые кажутся правдоподобными, но при дальнейшем рассмотрении таковыми не являются.
Вещи настолько сложны, насколько мы хотим их сделать. В большинстве случаев сложность — это оправдание либо нежелания что-то делать, либо незнания, как что-то делать.
Стремитесь делать вещи простыми. Стремитесь понять их. Боритесь за то, чтобы найти для них подходящие метафоры. Если вы не тратите энергию, пытаясь упростить вещи для своей аудитории, вы больше всего похожи на усложнятеля. Если так, то в следующий раз, когда вы соберётесь объяснить кому-то, почему что-то занимает так много времени, является таким сложным или требует выполнения 5 шагов перед началом, спросите себя: «Действительно ли я в это верю или я все усложняю, потому что либо не хочу, либо не знаю, как это сделать?»
Источник: https://kellblog.com/2015/05/13/career-advice-simplifiers-go-far-complexifiers-get-stuck/
👍13
Как бы вы изменили реляционную модель, чтобы увеличить производительность запросов к базе данных?
#Quiz #DataModeling
#Quiz #DataModeling
Anonymous Quiz
39%
Добавили бы избыточности в модель, тем самым уменьшив количество объединений в запросе
15%
Добавили бы представление с меньшим количеством колонок, чтобы упростить структуру запроса
16%
Убрали бы избыточность в модели, снизив количество хранимых данных, что ускоряет запросы
30%
Добавили бы целочисленный суррогатный ключ в каждую таблицу для более эффективного извлечения данных
👍6👎1
День 2075. #УрокиРазработки
Уроки 50 Лет Разработки ПО
Урок 26. Ваши переговорные позиции будут сильнее при наличии обосновывающих данных
Договариваясь о цене с продавцом в автосалоне подержанных авто, вы в невыгодном положении. Продавец имеет множество данных: о рынке цен на машины, о цене, по которой сдали это авто и о минимальной прибыли, которую нужно получить, о состоянии авто и т.п. У вас же, скорее всего, из информации будет только цена. Если вы не поленились и проведёте исследование рынка (а лучше и диагностику авто), то это вам поможет занять более сильную позицию.
Откуда вы взяли эту цифру?
Программный проект не имеет фиксированной цены, которую можно использовать в качестве отправной точки. Но та же ситуация может сложиться и на переговорах между заинтересованными сторонами.
Предположим, я — руководитель проекта. Клиент спрашивает, сколько времени потребуется и сколько это будет стоить. Основываясь на своём понимании проекта и опыте, я разрабатываю и представляю смету. Если спонсору не нравится моя оценка, возможны два исхода:
1) Я пытаюсь защитить свою оценку, не имея данных, а спонсор настаивает на сокращении затрат. Это не переговоры, а дебаты, которые я, скорее всего, проиграю.
2) Я, основываясь на данных, а не на эмоциях, описываю спонсору, как получена оценка, например:
- Я посоветовался с опытными членами команды, которые понимают, какого объёма работы требует новый проект.
- Мы оценили размер проекта на основе имеющейся информации и при этом учли фактор неопредёленности и ожидаемого разрастания, основываясь на прошлом опыте.
- Мы пересмотрели наш прошлый опыт работы с аналогичными проектами и т.д.
Если клиент по-прежнему не соглашается с оценкой, мы можем обсудить факты. Возможно, проект не похож ни на что сделанное нами ранее и наши исходные данные неактуальны. Это увеличивает риски и неопределённость оценок. Может, мы недостаточно хорошо понимаем проект, чтобы прийти к более реалистичной оценке. Придётся двигаться постепенно, оценивая каждый фрагмент по мере продвижения. Это снова порождает некую неопределенность в отношении сроков завершения проекта и его конечной стоимости. Однако наши базовые данные и процесс аналитической оценки послужат основой для сбалансированного обсуждения реального положения дел.
Принципиальные переговоры
Каждый раз, когда возникает разрыв между ожиданиями или требованиями заинтересованной стороны и вашим прогнозом в виде оценки, необходимо провести переговоры. Принципиальные переговоры — это метод достижения взаимоприемлемых соглашений. Они базируются на четырёх принципах:
1) Отделите людей от задач. Если обсуждение сводится к личной борьбе между вами и кем-то обладающим большей властью, то вы гарантированно проиграете, если не сможете привести убедительные доводы в свою пользу.
2) Сосредоточьтесь на интересах, а не на позициях. Не упорствуйте бездумно в защите своей оценки. Постарайтесь понять интересы другой стороны. Возможно, есть способ удовлетворить и их, и ваши интересы, изменив формулировку задачи или предлагаемое решение.
3) Придумывайте варианты для взаимной выгоды. Если вас вынуждают дать обещание, которое, как вы знаете, команда не сможет выполнить, ищите альтернативные взаимоприемлемые исходы с реалистичными целями, которых вы действительно сможете достичь. По результатам большинства успешных переговоров ни одна из сторон не получает всего, чего хочет, но обе стороны могут смириться с результатом — компромиссом.
4) Настаивайте на использовании объективных критериев. Здесь пригодятся ваши данные. Используйте данные для обоснования своих оценок и уважайте данные, представленные партнёром по переговорам.
Никто не может точно предсказать будущее. Лучшее, что можно сделать, — экстраполировать предыдущий опыт, внести коррективы там, где это оправданно, и признать неопределённость. Пусть за вас говорят данные, и предложите другой переговорной стороне поделиться своими данными. Возможно, так вы достигнете согласия и получите приемлемый результат.
Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 4.
Уроки 50 Лет Разработки ПО
Урок 26. Ваши переговорные позиции будут сильнее при наличии обосновывающих данных
Договариваясь о цене с продавцом в автосалоне подержанных авто, вы в невыгодном положении. Продавец имеет множество данных: о рынке цен на машины, о цене, по которой сдали это авто и о минимальной прибыли, которую нужно получить, о состоянии авто и т.п. У вас же, скорее всего, из информации будет только цена. Если вы не поленились и проведёте исследование рынка (а лучше и диагностику авто), то это вам поможет занять более сильную позицию.
Откуда вы взяли эту цифру?
Программный проект не имеет фиксированной цены, которую можно использовать в качестве отправной точки. Но та же ситуация может сложиться и на переговорах между заинтересованными сторонами.
Предположим, я — руководитель проекта. Клиент спрашивает, сколько времени потребуется и сколько это будет стоить. Основываясь на своём понимании проекта и опыте, я разрабатываю и представляю смету. Если спонсору не нравится моя оценка, возможны два исхода:
1) Я пытаюсь защитить свою оценку, не имея данных, а спонсор настаивает на сокращении затрат. Это не переговоры, а дебаты, которые я, скорее всего, проиграю.
2) Я, основываясь на данных, а не на эмоциях, описываю спонсору, как получена оценка, например:
- Я посоветовался с опытными членами команды, которые понимают, какого объёма работы требует новый проект.
- Мы оценили размер проекта на основе имеющейся информации и при этом учли фактор неопредёленности и ожидаемого разрастания, основываясь на прошлом опыте.
- Мы пересмотрели наш прошлый опыт работы с аналогичными проектами и т.д.
Если клиент по-прежнему не соглашается с оценкой, мы можем обсудить факты. Возможно, проект не похож ни на что сделанное нами ранее и наши исходные данные неактуальны. Это увеличивает риски и неопределённость оценок. Может, мы недостаточно хорошо понимаем проект, чтобы прийти к более реалистичной оценке. Придётся двигаться постепенно, оценивая каждый фрагмент по мере продвижения. Это снова порождает некую неопределенность в отношении сроков завершения проекта и его конечной стоимости. Однако наши базовые данные и процесс аналитической оценки послужат основой для сбалансированного обсуждения реального положения дел.
Принципиальные переговоры
Каждый раз, когда возникает разрыв между ожиданиями или требованиями заинтересованной стороны и вашим прогнозом в виде оценки, необходимо провести переговоры. Принципиальные переговоры — это метод достижения взаимоприемлемых соглашений. Они базируются на четырёх принципах:
1) Отделите людей от задач. Если обсуждение сводится к личной борьбе между вами и кем-то обладающим большей властью, то вы гарантированно проиграете, если не сможете привести убедительные доводы в свою пользу.
2) Сосредоточьтесь на интересах, а не на позициях. Не упорствуйте бездумно в защите своей оценки. Постарайтесь понять интересы другой стороны. Возможно, есть способ удовлетворить и их, и ваши интересы, изменив формулировку задачи или предлагаемое решение.
3) Придумывайте варианты для взаимной выгоды. Если вас вынуждают дать обещание, которое, как вы знаете, команда не сможет выполнить, ищите альтернативные взаимоприемлемые исходы с реалистичными целями, которых вы действительно сможете достичь. По результатам большинства успешных переговоров ни одна из сторон не получает всего, чего хочет, но обе стороны могут смириться с результатом — компромиссом.
4) Настаивайте на использовании объективных критериев. Здесь пригодятся ваши данные. Используйте данные для обоснования своих оценок и уважайте данные, представленные партнёром по переговорам.
Никто не может точно предсказать будущее. Лучшее, что можно сделать, — экстраполировать предыдущий опыт, внести коррективы там, где это оправданно, и признать неопределённость. Пусть за вас говорят данные, и предложите другой переговорной стороне поделиться своими данными. Возможно, так вы достигнете согласия и получите приемлемый результат.
Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 4.
👍14
День 2076. #ЧтоНовенького
Организуем Точки Останова
Если в вашем проекте множество точек останова, новая функция группировки точек останова в Visual Studio 2022 поможет легко их классифицировать, включать и отключать по группам.
Группировка точек останова позволяет создавать пользовательские коллекции точек останова и применять к ним различные действия. Например, включать или отключать все точки останова в группе или задавать для них условия и действия или даже делать всю группу зависимой от других точек останова.
Также можно отметить выбранную группу точек останова как группу по умолчанию, гарантируя, что все вновь добавленные точки останова будут автоматически включаться в эту группу.
Чтобы создать группу точек останова, щелкните правой кнопкой мыши на любую точку останова в окне Breakpoints и выберите Add to Group > New Group (Добавить в группу > Новая группа). Вы можете назвать группу и добавить описание, если хотите. Добавлять точки останова в группу можно простым перетаскиванием или через контекстное меню.
Чтобы установить группу точек останова в качестве группы по умолчанию, просто щелкните правой кнопкой мыши по группе и выберите Set as Default Group (Установить как группу по умолчанию). Группа по умолчанию будет обозначена жирным шрифтом. Если у вас есть группа точек останова по умолчанию, все новые точки останова, которые вы добавляете в код, будут автоматически добавляться в эту группу.
Вы можете получить доступ ко всем действиям группы точек останова из контекстного меню или панели инструментов в окне Breakpoints.
Источник: https://devblogs.microsoft.com/visualstudio/organize-your-breakpoints-like-a-pro/
Организуем Точки Останова
Если в вашем проекте множество точек останова, новая функция группировки точек останова в Visual Studio 2022 поможет легко их классифицировать, включать и отключать по группам.
Группировка точек останова позволяет создавать пользовательские коллекции точек останова и применять к ним различные действия. Например, включать или отключать все точки останова в группе или задавать для них условия и действия или даже делать всю группу зависимой от других точек останова.
Также можно отметить выбранную группу точек останова как группу по умолчанию, гарантируя, что все вновь добавленные точки останова будут автоматически включаться в эту группу.
Чтобы создать группу точек останова, щелкните правой кнопкой мыши на любую точку останова в окне Breakpoints и выберите Add to Group > New Group (Добавить в группу > Новая группа). Вы можете назвать группу и добавить описание, если хотите. Добавлять точки останова в группу можно простым перетаскиванием или через контекстное меню.
Чтобы установить группу точек останова в качестве группы по умолчанию, просто щелкните правой кнопкой мыши по группе и выберите Set as Default Group (Установить как группу по умолчанию). Группа по умолчанию будет обозначена жирным шрифтом. Если у вас есть группа точек останова по умолчанию, все новые точки останова, которые вы добавляете в код, будут автоматически добавляться в эту группу.
Вы можете получить доступ ко всем действиям группы точек останова из контекстного меню или панели инструментов в окне Breakpoints.
Источник: https://devblogs.microsoft.com/visualstudio/organize-your-breakpoints-like-a-pro/
👍24
День 2077. #BlazorBasics
Основы Blazor. Разбираем Шаблон Проекта Веб-Приложения Blazor. Начало
Решение о том, какой шаблон Blazor использовать, зависит от типа приложения, которое вы хотите создать. ASP.NET Core в .NET 8 вышел со значительными обновлениями архитектуры Blazor, которые включают новые режимы рендеринга, обеспечивающие большую производительность и гибкость.
Основы режимов рендеринга
ASP.NET Core с .NET 8 поддерживает 4 режима рендеринга.
1. Static Server
Статический SSR (Server Side Rendering) отображает статический HTML на сервере с помощью компонентов ASP.NET Razor. Как следует из названия, статический SSR не предлагает никакой интерактивности и полагается на стандартные POST-запросы веб-формы.
2. Interactive Server
Интерактивный SSR с использованием Blazor Server использует соединение SignalR для передачи событий и обновлений между сервером и веб-браузером.
3. Interactive WebAssembly
Interactive WebAssembly использует Blazor WebAssembly для рендеринга компонентов на клиенте. Логика приложения выполняется средой выполнения .NET WebAssembly.
4. Interactive Auto
Interactive Auto изначально будет выполнять рендеринг с использованием Blazor Server. Пока ресурсы для Blazor WebAssembly загружаются в браузер, приложение использует Blazor Server. После кэширования ресурсов Blazor WebAssembly последующие посещения будут работать с использованием Blazor WebAssembly.
Выбор правильного шаблона
В настоящее время существует довольно много вариантов шаблонов для Blazor. Решение о том, какой шаблон использовать, будет зависеть от типа приложения, которое вы хотите создать. Здесь мы сосредоточимся на шаблоне Blazor Web App, но сначала рассмотрим каждый вариант, чтобы понять различия (см. картинку).
- Blazor Web App — шаблон для создания приложения Blazor с серверным рендерингом и дополнительными режимами интерактивности сервера и клиента.
- Blazor Standalone WebAssembly App — используется для создания приложения Blazor WebAssembly с клиентским рендерингом и интерактивностью. Он не включает в себя серверный проект в решении. Этот шаблон идеально подходит для прогрессивных веб-приложений (PWA). Контент PWA можно добавить, отметив опцию Progressive Web Application во время настройки.
- Blazor Server App — используется для создания приложения Blazor с глобальной серверной интерактивностью. Шаблон предназначен только для запуска новых приложений .NET 6 и 7. Для приложений .NET 8 используйте шаблон Blazor Web App.
- Blazor Empty — базовая версия шаблона Server App. Предназначен только для запуска новых приложений .NET 6 и 7.
- .NET MAUI Blazor Hybrid App — используется для создания гибридного приложения Blazor и .NET MAUI. Идеально подходит для приложений, которые могут работать в Интернете, на настольных компьютерах и мобильных устройствах.
Новый шаблон Blazor Web App был создан как отправная точка для старта разработки под Blazor. В нём можно использовать несколько параметров для настройки генерируемого кода.
Продолжение следует…
Источник: https://www.telerik.com/blogs/unified-blazor-web-app-project-template-fully-explained
Основы Blazor. Разбираем Шаблон Проекта Веб-Приложения Blazor. Начало
Решение о том, какой шаблон Blazor использовать, зависит от типа приложения, которое вы хотите создать. ASP.NET Core в .NET 8 вышел со значительными обновлениями архитектуры Blazor, которые включают новые режимы рендеринга, обеспечивающие большую производительность и гибкость.
Основы режимов рендеринга
ASP.NET Core с .NET 8 поддерживает 4 режима рендеринга.
1. Static Server
Статический SSR (Server Side Rendering) отображает статический HTML на сервере с помощью компонентов ASP.NET Razor. Как следует из названия, статический SSR не предлагает никакой интерактивности и полагается на стандартные POST-запросы веб-формы.
2. Interactive Server
Интерактивный SSR с использованием Blazor Server использует соединение SignalR для передачи событий и обновлений между сервером и веб-браузером.
3. Interactive WebAssembly
Interactive WebAssembly использует Blazor WebAssembly для рендеринга компонентов на клиенте. Логика приложения выполняется средой выполнения .NET WebAssembly.
4. Interactive Auto
Interactive Auto изначально будет выполнять рендеринг с использованием Blazor Server. Пока ресурсы для Blazor WebAssembly загружаются в браузер, приложение использует Blazor Server. После кэширования ресурсов Blazor WebAssembly последующие посещения будут работать с использованием Blazor WebAssembly.
Выбор правильного шаблона
В настоящее время существует довольно много вариантов шаблонов для Blazor. Решение о том, какой шаблон использовать, будет зависеть от типа приложения, которое вы хотите создать. Здесь мы сосредоточимся на шаблоне Blazor Web App, но сначала рассмотрим каждый вариант, чтобы понять различия (см. картинку).
- Blazor Web App — шаблон для создания приложения Blazor с серверным рендерингом и дополнительными режимами интерактивности сервера и клиента.
- Blazor Standalone WebAssembly App — используется для создания приложения Blazor WebAssembly с клиентским рендерингом и интерактивностью. Он не включает в себя серверный проект в решении. Этот шаблон идеально подходит для прогрессивных веб-приложений (PWA). Контент PWA можно добавить, отметив опцию Progressive Web Application во время настройки.
- Blazor Server App — используется для создания приложения Blazor с глобальной серверной интерактивностью. Шаблон предназначен только для запуска новых приложений .NET 6 и 7. Для приложений .NET 8 используйте шаблон Blazor Web App.
- Blazor Empty — базовая версия шаблона Server App. Предназначен только для запуска новых приложений .NET 6 и 7.
- .NET MAUI Blazor Hybrid App — используется для создания гибридного приложения Blazor и .NET MAUI. Идеально подходит для приложений, которые могут работать в Интернете, на настольных компьютерах и мобильных устройствах.
Новый шаблон Blazor Web App был создан как отправная точка для старта разработки под Blazor. В нём можно использовать несколько параметров для настройки генерируемого кода.
Продолжение следует…
Источник: https://www.telerik.com/blogs/unified-blazor-web-app-project-template-fully-explained
👍21
День 2078. #BlazorBasics
Основы Blazor. Разбираем Шаблон Проекта Веб-Приложения Blazor. Продолжение
Начало
Базовая конфигурация
Диалоговое окно Blazor Web App (см. картинку) предлагает много параметров для создания нового приложения Blazor: аутентификация, режим рендеринга, местоположение интерактивности и многое другое. Рассмотрим каждый набор параметров, чтобы понять, как это влияет на сгенерированный контент.
Базовое приложение Blazor
С этой конфигурацией приложение не будет иметь интерактивности, будет включать только файлы, необходимые для запуска приложения, и будет использовать статический рендеринг на стороне сервера.
Кроме того, мы отключим параметр Include sample pages (Включить примеры страниц) и выберем None (Нет) для Interactive render mode (Режим интерактивного рендеринга) (см. картинку).
Поскольку это «голая» конфигурация, каждый файл, включённый в это решение, будет отображаться во всех проектах, хотя иногда файлы будут включать дополнительный код для поддержки определённых функций.
Компоненты HeadOutlet и Routes являются дочерними элементами компонента App, и их параметры могут различаться в зависимости от выбранного режима рендеринга.
Запуск «голого» приложения отобразит домашнюю страницу с “Hello, world!”.
Такой вариант подходит для начала с нуля, т.к. присутствует только минимальный набор компонентов.
Добавление примеров страниц
Если создать проект с опцией «Включить примеры страниц», приложение не будет иметь интерактивности, но будет включать статические ресурсы для предоставления базовой темы, элементы навигации и образец компонента для отображения данных.
Также добавятся примеры компонента страницы (Weather) и меню (NavMenu). В компоненте Weather
Эта конфигурация является хорошим началом для приложений, которым не требуется интерактивность. Дополнительные примеры тем и компонентов полезны для быстрого начала работы. Далее рассмотрим интерактивность сервера.
Продолжение следует...
Источник: https://www.telerik.com/blogs/unified-blazor-web-app-project-template-fully-explained
Основы Blazor. Разбираем Шаблон Проекта Веб-Приложения Blazor. Продолжение
Начало
Базовая конфигурация
Диалоговое окно Blazor Web App (см. картинку) предлагает много параметров для создания нового приложения Blazor: аутентификация, режим рендеринга, местоположение интерактивности и многое другое. Рассмотрим каждый набор параметров, чтобы понять, как это влияет на сгенерированный контент.
Базовое приложение Blazor
С этой конфигурацией приложение не будет иметь интерактивности, будет включать только файлы, необходимые для запуска приложения, и будет использовать статический рендеринг на стороне сервера.
Кроме того, мы отключим параметр Include sample pages (Включить примеры страниц) и выберем None (Нет) для Interactive render mode (Режим интерактивного рендеринга) (см. картинку).
Поскольку это «голая» конфигурация, каждый файл, включённый в это решение, будет отображаться во всех проектах, хотя иногда файлы будут включать дополнительный код для поддержки определённых функций.
/wwwroot — статические ресурсы: CSS, JavaScript, JSON, изображения и HTML. Содержимое этой папки всегда доступно извне после публикации приложения./Components — папка по умолчанию для компонентов приложения. Папки в Blazor автоматически определяют пространство имён компонента, если не указано иное. /../Layout — компоненты макета страницы. /../../MainLayout.razor — макет по умолчанию для приложения. /../../MainLayout.razor.css — CSS для компонента MainLayout. /../Pages – компоненты страниц. Они имеют директиву маршрута и могут быть связаны с URL. /../../Error.razor – страница ошибок по умолчанию. /../../Home.razor – домашняя страница по умолчанию. Отображается при переходе на корневой URL приложения "/". /../_Imports.razor – для глобальных директив using для всех файлов .razor в этой папке или в дочерних. /../App.razor – первый компонент, который рендерит приложение. Содержит базовый HTML приложения: теги html, head и body, ссылки на статические ресурсы (CSS, JS, шрифты и т.п.). Компоненты HeadOutlet и Routes являются дочерними элементами компонента App, и их параметры могут различаться в зависимости от выбранного режима рендеринга.
/../Routes.razor — маршрутизатор приложения./appsettings.json — настройки приложения./Program.cs — точка входа приложения. Здесь определяется конфигурация.Запуск «голого» приложения отобразит домашнюю страницу с “Hello, world!”.
Такой вариант подходит для начала с нуля, т.к. присутствует только минимальный набор компонентов.
Добавление примеров страниц
Если создать проект с опцией «Включить примеры страниц», приложение не будет иметь интерактивности, но будет включать статические ресурсы для предоставления базовой темы, элементы навигации и образец компонента для отображения данных.
/wwwroot будет содержать минимизированный файл CSS Bootstrap и значок. Bootstrap используется для создания базовой темы для приложения. Кроме того, в файлы app.css и component.css будут добавлены темы.Также добавятся примеры компонента страницы (Weather) и меню (NavMenu). В компоненте Weather
@attribute [StreamRendering] демонстрирует пример длительного процесса рендеринга. StreamingRendering улучшает пользовательский опыт, перерисовывая компонент по мере обработки данных на сервере.Эта конфигурация является хорошим началом для приложений, которым не требуется интерактивность. Дополнительные примеры тем и компонентов полезны для быстрого начала работы. Далее рассмотрим интерактивность сервера.
Продолжение следует...
Источник: https://www.telerik.com/blogs/unified-blazor-web-app-project-template-fully-explained
👍13
День 2079. #BlazorBasics
Основы Blazor. Разбираем Шаблон Проекта Веб-Приложения Blazor. Продолжение
1. Основы режимов рендеринга
2. Базовая конфигурация
Параметр интерактивности Server
Существует три режима интерактивности: Server, WebAssembly и Auto. И для каждого можно выбрать место настройки интерактивности Global или Per Page/Component.
Когда интерактивность добавляется в приложение Blazor, файлы App.razor и Program.cs будут настроены с параметрами для желаемого режима интерактивности. Если включен параметр Include sample pages, примеры компонентов показывают, как пользоваться выбранным режимом.
Глобальный интерактивный сервер
Interactive render mode: Server
Interactivity location: Global
В режиме интерактивного сервера (см. картинку) Program.cs включает операторы для включения этой функции:
Настройка Global применит режим рендеринга приложения в App.razor. Экземпляры компонентов HeaderOutlet и Routes получат
Примеры компонентов Counter и Weather сгенерируются в соответствии с настройкой Global. Поскольку интерактивный режим был установлен в экземпляре компонента Routes, в примерах не нужно указывать режим рендеринга. В примере компонента Weather не будет
Эта конфигурация подходит для приложений, которые будут полностью интерактивными для всех компонентов.
Постраничный/Покомпонентный интерактивный сервер
Interactive render mode: Server
Interactivity location: Per Page/Component
Сгенерированный проект будет похож на предыдущий, но компоненты App, Counter и Weather будут немного отличаться.
При использовании параметра Per Page/Component App.razor не указывает режима рендеринга для экземпляров компонентов. Это позволяет любой странице или дочернему компоненту выбирать свой режим рендеринга. Если режим рендеринга не указан, то эти компоненты рендерятся статически (без интерактивности).
Чтобы продемонстрировать гибкость проекта Per Page/Component, образцы компонентов Counter и Weather включают соответствующие конфигурации. В код компонента Counter добавлен
Эта конфигурация подходит для приложений, которые необходимо оптимизировать с помощью статической серверной отрисовки, когда интерактивность не нужна. Для компонентов, требующих интерактивности сервера, эта функция может быть включена через атрибут
Далее рассмотрим параметры режима рендеринга WebAssembly.
Продолжение следует…
Источник: https://www.telerik.com/blogs/unified-blazor-web-app-project-template-fully-explained
Основы Blazor. Разбираем Шаблон Проекта Веб-Приложения Blazor. Продолжение
1. Основы режимов рендеринга
2. Базовая конфигурация
Параметр интерактивности Server
Существует три режима интерактивности: Server, WebAssembly и Auto. И для каждого можно выбрать место настройки интерактивности Global или Per Page/Component.
Когда интерактивность добавляется в приложение Blazor, файлы App.razor и Program.cs будут настроены с параметрами для желаемого режима интерактивности. Если включен параметр Include sample pages, примеры компонентов показывают, как пользоваться выбранным режимом.
Глобальный интерактивный сервер
Interactive render mode: Server
Interactivity location: Global
В режиме интерактивного сервера (см. картинку) Program.cs включает операторы для включения этой функции:
builder.Services.AddRazorComponents()
.AddInteractiveServerComponents();
app.MapRazorComponents<App>()
.AddInteractiveServerRenderMode();
Настройка Global применит режим рендеринга приложения в App.razor. Экземпляры компонентов HeaderOutlet и Routes получат
@rendermode="@InteractiveServer", т.е. любой дочерний элемент этих компонентов будет иметь интерактивность сервера.Примеры компонентов Counter и Weather сгенерируются в соответствии с настройкой Global. Поскольку интерактивный режим был установлен в экземпляре компонента Routes, в примерах не нужно указывать режим рендеринга. В примере компонента Weather не будет
@attribute [StreamRendering], поскольку интерактивность через событие OnInitializedAsync обеспечивает аналогичный опыт.Эта конфигурация подходит для приложений, которые будут полностью интерактивными для всех компонентов.
Постраничный/Покомпонентный интерактивный сервер
Interactive render mode: Server
Interactivity location: Per Page/Component
Сгенерированный проект будет похож на предыдущий, но компоненты App, Counter и Weather будут немного отличаться.
При использовании параметра Per Page/Component App.razor не указывает режима рендеринга для экземпляров компонентов. Это позволяет любой странице или дочернему компоненту выбирать свой режим рендеринга. Если режим рендеринга не указан, то эти компоненты рендерятся статически (без интерактивности).
Чтобы продемонстрировать гибкость проекта Per Page/Component, образцы компонентов Counter и Weather включают соответствующие конфигурации. В код компонента Counter добавлен
@rendermode InteractiveServer, указывающий, что он использует режим интерактивный сервер. Компонент Weather не требует интерактивности и отображается статически. @attribute [StreamRendering] используется для отображения сообщения «загрузка» во время загрузки данных компонента Weather. После загрузки данных StreamRendering обновляет компонент для окончательной отрисовки результатов.Эта конфигурация подходит для приложений, которые необходимо оптимизировать с помощью статической серверной отрисовки, когда интерактивность не нужна. Для компонентов, требующих интерактивности сервера, эта функция может быть включена через атрибут
rendermode. Далее рассмотрим параметры режима рендеринга WebAssembly.
Продолжение следует…
Источник: https://www.telerik.com/blogs/unified-blazor-web-app-project-template-fully-explained
👍12
День 2080. #BlazorBasics
Основы Blazor. Разбираем Шаблон Проекта Веб-Приложения Blazor. Продолжение
1. Основы режимов рендеринга
2. Базовая конфигурация
3. Параметр интерактивности Server
Параметр интерактивности WebAssembly
В отличие от режимов интерактивности сервера, которые создают только один проект на решение, параметры WebAssembly и Auto включают два проекта. Один проект - для приложения сервера, а другой — для интерактивных страниц и компонентов клиента.
Глобальная интерактивность WebAssembly
Interactive render mode: WebAssembly
Interactivity location: Global
В проекте сервера Program.cs включает операторы для активации интерактивности WebAssembly:
-
-
-
Настройка Global применит режим рендеринга приложения в App.razor. Экземпляры компонентов HeaderOutlet и Routes получат
Эта конфигурация подходит для приложений, которые используют интерактивность WebAssembly для всех компонентов, что снижает нагрузку на сервер.
Постраничный/Покомпонентный интерактивный WebAssembly
Interactive render mode: WebAssembly
Interactivity location: Per Page/Component
В этой конфигурации (см. картинку) компонент App.razor не указывает режима рендеринга для экземпляров компонентов. Страницы и компоненты выбирают свой режим рендеринга - по умолчанию рендерятся статически (без интерактивности). Для поддержки как серверных, так и клиентских компонентов компонент Route генерируется в проекте Server и ссылается на маршруты компонентов Client через свойство AdditionalAssemblies:
Counter — единственный интерактивный компонент в такой конфигурации, поэтому он размещается в проекте Client. Атрибут
Эта конфигурация подходит для приложений, которые необходимо оптимизировать с помощью статического рендеринга сервера, когда интерактивность не нужна. Для компонентов, которым требуется интерактивность WebAssembly, эту функцию можно включить с помощью атрибута
В заключение рассмотрим параметр режима рендеринга Auto.
Окончание следует…
Источник: https://www.telerik.com/blogs/unified-blazor-web-app-project-template-fully-explained
Основы Blazor. Разбираем Шаблон Проекта Веб-Приложения Blazor. Продолжение
1. Основы режимов рендеринга
2. Базовая конфигурация
3. Параметр интерактивности Server
Параметр интерактивности WebAssembly
В отличие от режимов интерактивности сервера, которые создают только один проект на решение, параметры WebAssembly и Auto включают два проекта. Один проект - для приложения сервера, а другой — для интерактивных страниц и компонентов клиента.
Глобальная интерактивность WebAssembly
Interactive render mode: WebAssembly
Interactivity location: Global
В проекте сервера Program.cs включает операторы для активации интерактивности WebAssembly:
-
AddInteractiveWebAssemblyComponents добавляет сервисы интерактивности на клиенте. -
AddInteractiveWebAssemblyRenderMode настраивает интерактивный рендеринг на стороне клиента.-
AddAdditionalAssemblies находит компоненты в клиентском приложении, создавая ссылку на серверное приложение.builder.Services.AddRazorComponents()
.AddInteractiveWebAssemblyComponents();
app.MapRazorComponents<App>()
.AddInteractiveWebAssemblyRenderMode()
.AddAdditionalAssemblies(typeof(Counter).Assembly);
Настройка Global применит режим рендеринга приложения в App.razor. Экземпляры компонентов HeaderOutlet и Routes получат
@rendermode="@InteractiveWebAssembly", т.е. любые дочерние компоненты этих компонентов будут иметь интерактивность WebAssembly. Файл Routes.razor создаётся в клиентском приложении, где происходит вся интерактивность.Эта конфигурация подходит для приложений, которые используют интерактивность WebAssembly для всех компонентов, что снижает нагрузку на сервер.
Постраничный/Покомпонентный интерактивный WebAssembly
Interactive render mode: WebAssembly
Interactivity location: Per Page/Component
В этой конфигурации (см. картинку) компонент App.razor не указывает режима рендеринга для экземпляров компонентов. Страницы и компоненты выбирают свой режим рендеринга - по умолчанию рендерятся статически (без интерактивности). Для поддержки как серверных, так и клиентских компонентов компонент Route генерируется в проекте Server и ссылается на маршруты компонентов Client через свойство AdditionalAssemblies:
csharp
<Router AppAssembly="@typeof(Program).Assembly" AdditionalAssemblies="new[] { typeof(Client._Imports).Assembly }">
…
</Router>
Counter — единственный интерактивный компонент в такой конфигурации, поэтому он размещается в проекте Client. Атрибут
@rendermode InteractiveWebAssembly в Counter указывает на его режим интерактивности. Остальные компоненты генерируются в проекте Server, поскольку они будут визуализироваться статически. Компонент Weather настроен с использованием StreamRendering.Эта конфигурация подходит для приложений, которые необходимо оптимизировать с помощью статического рендеринга сервера, когда интерактивность не нужна. Для компонентов, которым требуется интерактивность WebAssembly, эту функцию можно включить с помощью атрибута
rendermode. В заключение рассмотрим параметр режима рендеринга Auto.
Окончание следует…
Источник: https://www.telerik.com/blogs/unified-blazor-web-app-project-template-fully-explained
👍6
День 2081. #BlazorBasics
Основы Blazor. Разбираем Шаблон Проекта Веб-Приложения Blazor. Окончание
1. Основы режимов рендеринга
2. Базовая конфигурация
3. Параметр интерактивности Server
4. Параметр интерактивности WebAssembly
Параметр интерактивности Auto
Автоматическая интерактивная визуализация (см. картинку) будет использовать сервер или WebAssembly для интерактивности в зависимости от ресурсов, доступных на клиенте. Выбор параметра Auto (Server и WebAssembly) даст практически идентичные результаты, как и для интерактивности WebAssembly с соответствующими параметрами Global или Per Page/Component. Основные различия заключаются в файле Program.cs и использовании атрибутов
В серверном проекте файл
```csharp
builder.Services.AddRazorComponents()
.AddInteractiveServerComponents()
.AddInteractiveWebAssemblyComponents();
app.MapRazorComponents<App>()
.AddInteractiveServerRenderMode()
.AddInteractiveWebAssemblyRenderMode()
.AddAdditionalAssemblies(typeof(Counter).Assembly);
``
При выборе опции Global к экземпляру компонента Routes в App.razor применяется атрибут
Для опции Per Page/Component атрибут
Автоматический рендеринг обеспечивает баланс между серверным и WebAsembly режимами. Эта конфигурация подходит для приложений, которым может потребоваться оптимизировать начальное время загрузки приложения.
Примечание о параметре Authentication type (Тип аутентификации)
Параметр создаёт все файлы, необходимые для аутентификации пользователей и управления профилями пользователей. Для получения дополнительной информации по этой теме обратитесь к официальной документации.
Итого
Начало нового проекта Blazor в .NET 8 может показаться сложным на первый взгляд из-за обширного списка шаблонов и параметров. Шаблон Blazor Web App — лучшее решение для приложений Blazor, которые могут использовать статический рендеринг сервера (не PWA и не приложения Blazor Hybrid). Шаблон Blazor Web App объединяет все конфигурации Blazor в одну, предоставляя при этом несколько вариантов для выбора правильной отправной точки. Знание того, какие возможности требуются вашему приложению, определит, какие параметры следует выбрать, но в любом случае Blazor можно перенастроить вручную в любое время, если возникнут новые требования.
Источник: https://www.telerik.com/blogs/unified-blazor-web-app-project-template-fully-explained
Основы Blazor. Разбираем Шаблон Проекта Веб-Приложения Blazor. Окончание
1. Основы режимов рендеринга
2. Базовая конфигурация
3. Параметр интерактивности Server
4. Параметр интерактивности WebAssembly
Параметр интерактивности Auto
Автоматическая интерактивная визуализация (см. картинку) будет использовать сервер или WebAssembly для интерактивности в зависимости от ресурсов, доступных на клиенте. Выбор параметра Auto (Server и WebAssembly) даст практически идентичные результаты, как и для интерактивности WebAssembly с соответствующими параметрами Global или Per Page/Component. Основные различия заключаются в файле Program.cs и использовании атрибутов
rendermode в компонентах.В серверном проекте файл
Program.cs будет вызывать методы для активации интерактивности как WebAssembly, так и Server. Режимы визуализации приложения также настраиваются с помощью методов AddInteractiveWebAssemblyRenderMode и AddInteractiveServerRenderMode. Метод AddAdditionalAssemblies находит компоненты в клиентском приложении, создавая ссылку на серверное приложение.```csharp
builder.Services.AddRazorComponents()
.AddInteractiveServerComponents()
.AddInteractiveWebAssemblyComponents();
app.MapRazorComponents<App>()
.AddInteractiveServerRenderMode()
.AddInteractiveWebAssemblyRenderMode()
.AddAdditionalAssemblies(typeof(Counter).Assembly);
``
При выборе опции Global к экземпляру компонента Routes в App.razor применяется атрибут
InteractiveAuto. Поскольку режим устанавливается на корневом уровне приложения, все компоненты для этой настройки будут сгенерированы в проекте Client.Для опции Per Page/Component атрибут
InteractiveAuto отображается только в компоненте Counter. Все остальные компоненты используют статическую серверную визуализацию и генерируются в проекте Server.Автоматический рендеринг обеспечивает баланс между серверным и WebAsembly режимами. Эта конфигурация подходит для приложений, которым может потребоваться оптимизировать начальное время загрузки приложения.
Примечание о параметре Authentication type (Тип аутентификации)
Параметр создаёт все файлы, необходимые для аутентификации пользователей и управления профилями пользователей. Для получения дополнительной информации по этой теме обратитесь к официальной документации.
Итого
Начало нового проекта Blazor в .NET 8 может показаться сложным на первый взгляд из-за обширного списка шаблонов и параметров. Шаблон Blazor Web App — лучшее решение для приложений Blazor, которые могут использовать статический рендеринг сервера (не PWA и не приложения Blazor Hybrid). Шаблон Blazor Web App объединяет все конфигурации Blazor в одну, предоставляя при этом несколько вариантов для выбора правильной отправной точки. Знание того, какие возможности требуются вашему приложению, определит, какие параметры следует выбрать, но в любом случае Blazor можно перенастроить вручную в любое время, если возникнут новые требования.
Источник: https://www.telerik.com/blogs/unified-blazor-web-app-project-template-fully-explained
👍6
День 2082. #УрокиРазработки
Уроки 50 Лет Разработки ПО
Урок 27. Не записывая оценки и не сверяя их с тем, что произошло на самом деле, вы всегда будете строить догадки, а не оценивать. Начало
Все хотят знать, сколько времени займёт работа. Если она не является точной копией того, что вы делали раньше, вы должны оценить её, отталкиваясь от предыдущего аналогичного опыта. Но память часто подводит. Даже помня, сколько времени вы потратили, вы едва ли вспомните, сколько предполагалось потратить первоначально. Чтобы получать достаточно точные оценки, нужны данные, а не смутные воспоминания. Где взять эти данные?
Записывайте всё, что сделали сегодня, и завтра эти записи станут ретроспективными данными. Это единственный способ улучшить оценку затрат на выполнение предстоящих действий.
Если прогноз и реальность сильно расходятся, попробуйте выяснить причину и подумайте, как получить более реалистичную оценку для аналогичной работы в будущем. Пришлось ли выполнять больше задач, чем ожидали? Решение потребовало больше времени, чем предполагали? Были ли предположения о продуктивности чрезмерно оптимистичными? Помешали неожиданные факторы? По мере накопления данных вы сможете вычислять некие средние значения и получать более точные оценки. Без данных вы просто строите предположения.
Несколько источников данных за прошедший период
Есть четыре потенциальных источника данных за прошедший период.
Во-первых, личный опыт. Индивидуальная производительность существенно различается в зависимости от навыков и опыта того, кто выполняет работу. Зная, сколько времени потребуется другому разработчику, я не могу предсказать, сколько потребуется мне на то же самое.
- Создавайте список задач со всеми шагами, которые только можно придумать.
- Записывайте, сколько времени потребовалось для выполнения каждого пункта.
- Исходя из этих данных, оцените, сколько времени займет похожая работа.
- Завершив её, сравните оценки с фактическим временем.
Наличие этих данных поможет точнее оценить затраты в будущем.
Они также напомнят о задачах, которые вы иначе могли бы пропустить. Люди часто забывают запланировать время для доработки недостатков, выявленных после тестирования или рецензирования.
Во-вторых, текущий проект. Наиболее значимые данные поступают из недавно завершённых частей текущего проекта. Они отображают влияние окружения, культуры, процессов и инструментов на продуктивность текущей команды. Проекты, использующие методы Agile-разработки, хорошо подходят для сбора таких данных. Наиболее точные прогнозы будущей продуктивности основаны на средней скорости последних итераций при условии, что состав команды, характер и качество выполняемой работы остаются постоянными.
Наконец, статистика по ранее завершённым проектам в вашей организации и средние показатели по отрасли для проектов, подобных вашему. Они плохо подходят для предсказания вашего будущего, поскольку различия между проектами, командами и организациями увеличивают неопределённость. И всё же лучше полагаться на такого рода исторические данные, чем давать оценки, основываясь исключительно на смутных воспоминаниях или догадках.
Окончание следует…
Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 4.
Уроки 50 Лет Разработки ПО
Урок 27. Не записывая оценки и не сверяя их с тем, что произошло на самом деле, вы всегда будете строить догадки, а не оценивать. Начало
Все хотят знать, сколько времени займёт работа. Если она не является точной копией того, что вы делали раньше, вы должны оценить её, отталкиваясь от предыдущего аналогичного опыта. Но память часто подводит. Даже помня, сколько времени вы потратили, вы едва ли вспомните, сколько предполагалось потратить первоначально. Чтобы получать достаточно точные оценки, нужны данные, а не смутные воспоминания. Где взять эти данные?
Записывайте всё, что сделали сегодня, и завтра эти записи станут ретроспективными данными. Это единственный способ улучшить оценку затрат на выполнение предстоящих действий.
Если прогноз и реальность сильно расходятся, попробуйте выяснить причину и подумайте, как получить более реалистичную оценку для аналогичной работы в будущем. Пришлось ли выполнять больше задач, чем ожидали? Решение потребовало больше времени, чем предполагали? Были ли предположения о продуктивности чрезмерно оптимистичными? Помешали неожиданные факторы? По мере накопления данных вы сможете вычислять некие средние значения и получать более точные оценки. Без данных вы просто строите предположения.
Несколько источников данных за прошедший период
Есть четыре потенциальных источника данных за прошедший период.
Во-первых, личный опыт. Индивидуальная производительность существенно различается в зависимости от навыков и опыта того, кто выполняет работу. Зная, сколько времени потребуется другому разработчику, я не могу предсказать, сколько потребуется мне на то же самое.
- Создавайте список задач со всеми шагами, которые только можно придумать.
- Записывайте, сколько времени потребовалось для выполнения каждого пункта.
- Исходя из этих данных, оцените, сколько времени займет похожая работа.
- Завершив её, сравните оценки с фактическим временем.
Наличие этих данных поможет точнее оценить затраты в будущем.
Они также напомнят о задачах, которые вы иначе могли бы пропустить. Люди часто забывают запланировать время для доработки недостатков, выявленных после тестирования или рецензирования.
Во-вторых, текущий проект. Наиболее значимые данные поступают из недавно завершённых частей текущего проекта. Они отображают влияние окружения, культуры, процессов и инструментов на продуктивность текущей команды. Проекты, использующие методы Agile-разработки, хорошо подходят для сбора таких данных. Наиболее точные прогнозы будущей продуктивности основаны на средней скорости последних итераций при условии, что состав команды, характер и качество выполняемой работы остаются постоянными.
Наконец, статистика по ранее завершённым проектам в вашей организации и средние показатели по отрасли для проектов, подобных вашему. Они плохо подходят для предсказания вашего будущего, поскольку различия между проектами, командами и организациями увеличивают неопределённость. И всё же лучше полагаться на такого рода исторические данные, чем давать оценки, основываясь исключительно на смутных воспоминаниях или догадках.
Окончание следует…
Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 4.
👍12
День 2083. #УрокиРазработки
Уроки 50 Лет Разработки ПО
Урок 27. Не записывая оценки и не сверяя их с тем, что произошло на самом деле, вы всегда будете строить догадки, а не оценивать. Окончание
Начало
Характеристики ПО
Чтобы проанализировать опыт предыдущих проектов и составить более обоснованные планы, необходимо собрать некоторые характеристики. Люди могут измерять различные аспекты программных проектов на трёх уровнях: индивидуальный участник, проектная группа и организация-разработчик.
Знание следующих характеристик может дать довольно полное представление о вашей работе:
1. Объём
Выберите некую меру размера, значимую для той работы, которую вы выполняете. Это может быть количество требований, пунктов в списке функциональных особенностей, пользовательских историй, классов и количество строк исходного кода (хотя последний пункт выглядит довольно сомнительным).
2. Трудозатраты
Фиксируйте трудозатраты, необходимые для создания каждого проекта или отдельной его части. Понимая возможные трудозатраты и зная объём работы, вы сможете рассчитать производительность.
3. Время
Запишите расчётную и фактическую продолжительность выполнения работ в единицах календарного времени. На преобразование рабочих усилий в календарное время влияет большое количество факторов.
4. Уровень качества
Подсчёт дефектов, обнаруженных различными способами, показывает, с помощью каких методов обеспечения качества лучше выявлять ошибки и где можно изыскать дополнительные резервы для улучшения качества. Учёт времени, затраченного на доработку и исправление дефектов, тоже помогает в планировании. Если вы знаете, где возникла ошибка (конкретная итерация, требование или действие), то будете более отчётливо понимать, на чём следует сосредоточить дополнительные усилия, чтобы обеспечить качество в будущем.
В своей книге «Сколько стоит программный проект» Стив Макконнелл указывает на многочисленные проблемы, связанные с мерами измерения в каждой из этих категорий. Макконнелл подчёркивает важность чёткого определения каждой собираемой метрики, что позволяет людям записывать данные в единообразной форме. Если вы не сравниваете результаты с внешним эталоном, то согласованность внутренних измерений важнее абсолютной истины. Например, все члены команды должны одинаково оценивать свои усилия и подсчитывать дефекты. Предположим, одни члены команды добавляют время на отладку и доработку в общее время разработки, другие относят их к этапу тестирования, а третьи вообще не учитывают его. Такое смешивание не способствует обоснованному предсказанию будущего.
Необходимость записывать метрики, характеризующие ПО, нервирует некоторых людей. Определение характеристик ПО действительно является деликатной областью с множеством потенциальных ловушек. Золотое правило гласит, что данные нужно использовать для изучения и совершенствования, а не для наказания или вознаграждения кого-либо. Людей также часто беспокоит необходимость тратить время на сбор и анализ данных, но, как показывает опыт, запись базовой информации о проектной деятельности не требует особых затрат. Эта привычка быстро становится частью рабочего процесса.
Итого
Спустя долгое время после завершения работы у вас не получится точно восстановить её характеристики. Поэтому создайте механизмы для сбора и сохранения данных по мере продвижения. Ретроспектива в конце цикла разработки даёт хорошую возможность собрать данные для оценки прошлого и планирования будущего. Если вы потратите немного времени на запись происходившего сегодня, то завтра у вас будут исторические данные, которые помогут оценить следующую часть работы.
Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 4.
Уроки 50 Лет Разработки ПО
Урок 27. Не записывая оценки и не сверяя их с тем, что произошло на самом деле, вы всегда будете строить догадки, а не оценивать. Окончание
Начало
Характеристики ПО
Чтобы проанализировать опыт предыдущих проектов и составить более обоснованные планы, необходимо собрать некоторые характеристики. Люди могут измерять различные аспекты программных проектов на трёх уровнях: индивидуальный участник, проектная группа и организация-разработчик.
Знание следующих характеристик может дать довольно полное представление о вашей работе:
1. Объём
Выберите некую меру размера, значимую для той работы, которую вы выполняете. Это может быть количество требований, пунктов в списке функциональных особенностей, пользовательских историй, классов и количество строк исходного кода (хотя последний пункт выглядит довольно сомнительным).
2. Трудозатраты
Фиксируйте трудозатраты, необходимые для создания каждого проекта или отдельной его части. Понимая возможные трудозатраты и зная объём работы, вы сможете рассчитать производительность.
3. Время
Запишите расчётную и фактическую продолжительность выполнения работ в единицах календарного времени. На преобразование рабочих усилий в календарное время влияет большое количество факторов.
4. Уровень качества
Подсчёт дефектов, обнаруженных различными способами, показывает, с помощью каких методов обеспечения качества лучше выявлять ошибки и где можно изыскать дополнительные резервы для улучшения качества. Учёт времени, затраченного на доработку и исправление дефектов, тоже помогает в планировании. Если вы знаете, где возникла ошибка (конкретная итерация, требование или действие), то будете более отчётливо понимать, на чём следует сосредоточить дополнительные усилия, чтобы обеспечить качество в будущем.
В своей книге «Сколько стоит программный проект» Стив Макконнелл указывает на многочисленные проблемы, связанные с мерами измерения в каждой из этих категорий. Макконнелл подчёркивает важность чёткого определения каждой собираемой метрики, что позволяет людям записывать данные в единообразной форме. Если вы не сравниваете результаты с внешним эталоном, то согласованность внутренних измерений важнее абсолютной истины. Например, все члены команды должны одинаково оценивать свои усилия и подсчитывать дефекты. Предположим, одни члены команды добавляют время на отладку и доработку в общее время разработки, другие относят их к этапу тестирования, а третьи вообще не учитывают его. Такое смешивание не способствует обоснованному предсказанию будущего.
Необходимость записывать метрики, характеризующие ПО, нервирует некоторых людей. Определение характеристик ПО действительно является деликатной областью с множеством потенциальных ловушек. Золотое правило гласит, что данные нужно использовать для изучения и совершенствования, а не для наказания или вознаграждения кого-либо. Людей также часто беспокоит необходимость тратить время на сбор и анализ данных, но, как показывает опыт, запись базовой информации о проектной деятельности не требует особых затрат. Эта привычка быстро становится частью рабочего процесса.
Итого
Спустя долгое время после завершения работы у вас не получится точно восстановить её характеристики. Поэтому создайте механизмы для сбора и сохранения данных по мере продвижения. Ретроспектива в конце цикла разработки даёт хорошую возможность собрать данные для оценки прошлого и планирования будущего. Если вы потратите немного времени на запись происходившего сегодня, то завтра у вас будут исторические данные, которые помогут оценить следующую часть работы.
Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 4.
👍6
День 2084. #ЧтоНовенького
Готовимся к .NET 9
Релиз .NET 9 уже скоро. .NET 9 RC 1 (вышел 10 сентября) уже поставляется с лицензией Go-Live, что означает, что он поддерживается Microsoft для использования в производственных средах. Если вы в настоящее время используете .NET 6 или более новую версию, процесс миграции на .NET 9 довольно прост. Вот несколько ключевых шагов.
1. Обновите зависимости
Это всегда хорошая практика перед миграцией, многие проблемы несовместимости часто решаются таким образом. Отличным инструментом, помогающим в этом, является dotnet-outdated. Чтобы проверить наличие устаревших пакетов, выполните:
Он даже может обновить пакеты для вас.
2. Удалите устаревшие целевые фреймворки
Если вы всё ещё используете устаревшие фреймворки, такие как net7.0, пришло время избавиться от них. Многие новые сборки .NET 9 нацелены только на .NET 8 и выше. Если вам нужно сохранить совместимость с .NET 6, вы можете использовать условные операторы в ссылках на пакеты в качестве временного решения, например:
3. Обновите global.json
Простой способ обновить global.json — удалить его и запустить
Эта команда создаст global.json, соответствующий версии SDK, который будет без проблем работать в вашем конвейере CI/CD.
4. Добавьте целевую платформу net9.0
Добавьте моникер целевой платформы net9.0 в проект, используя свойство MSBuild TargetFrameworks (если вы используете TargetFramework сегодня и хотите использовать многоцелевую платформу, её необходимо указать в TargetFrameworks), например:
После 12 ноября 2024 поддерживаемыми платформами останутся:
- .NET 8 (Long Term Support - до 10 ноября 2026)
- .NET 9 (Standard Term Support - 18 месяцев с даты релиза).
5. Соберите проект и устраните проблемы
После того, как вы всё настроите, соберите решение и устраните все возникающие проблемы:
- Проблемы с исходным кодом. Возможно, у вас есть методы, которые будут конфликтовать с новинками .NET 9, например, метод расширения Index для IEnumerable<T>.
- Ошибки/предупреждения зависимостей. .NET 9 SDK более открыто сообщает о пакетах с проблемами безопасности или устаревшими зависимостями. Даже транзитивные зависимости (те, на которые вы не ссылаетесь напрямую) могут вызывать предупреждения. Здесь поможет команда
Вы можете либо закрепить определённые версии, либо перейти на заменяющие пакеты. Одним из распространённых примеров является System.Text.Json, на старые и устаревшие версии которого ссылаются многие пакеты. Явно добавляя ссылку на пакет, вы закрепляете версию, используемую вашим проектом, например:
Централизованное управление пакетами — хороший вариант для решения в одном месте для обработки версий пакетов, включая транзитивные.
Итого
Фактически, вы можете начать использовать новый .NET 9 SDK сегодня, продолжая ориентироваться на старые фреймворки и получая доступ к новым функциям времени сборки, оставаясь в текущей среде выполнения. В целом, особых проблем быть не должно.
Источник: https://www.devlead.se/posts/2024/2024-09-22-preparing-for-dotnet-9
Готовимся к .NET 9
Релиз .NET 9 уже скоро. .NET 9 RC 1 (вышел 10 сентября) уже поставляется с лицензией Go-Live, что означает, что он поддерживается Microsoft для использования в производственных средах. Если вы в настоящее время используете .NET 6 или более новую версию, процесс миграции на .NET 9 довольно прост. Вот несколько ключевых шагов.
1. Обновите зависимости
Это всегда хорошая практика перед миграцией, многие проблемы несовместимости часто решаются таким образом. Отличным инструментом, помогающим в этом, является dotnet-outdated. Чтобы проверить наличие устаревших пакетов, выполните:
dotnet outdated <solution/project folder>
Он даже может обновить пакеты для вас.
2. Удалите устаревшие целевые фреймворки
Если вы всё ещё используете устаревшие фреймворки, такие как net7.0, пришло время избавиться от них. Многие новые сборки .NET 9 нацелены только на .NET 8 и выше. Если вам нужно сохранить совместимость с .NET 6, вы можете использовать условные операторы в ссылках на пакеты в качестве временного решения, например:
<PackageReference Condition=" '$(TargetFramework)' == 'net6.0' " Include="Verify.Http" Version="5.0.1" />
<PackageReference Condition=" '$(TargetFramework)' != 'net6.0' " Include="Verify.Http" Version="6.3.0" />
3. Обновите global.json
Простой способ обновить global.json — удалить его и запустить
dotnet new globaljson
Эта команда создаст global.json, соответствующий версии SDK, который будет без проблем работать в вашем конвейере CI/CD.
4. Добавьте целевую платформу net9.0
Добавьте моникер целевой платформы net9.0 в проект, используя свойство MSBuild TargetFrameworks (если вы используете TargetFramework сегодня и хотите использовать многоцелевую платформу, её необходимо указать в TargetFrameworks), например:
<TargetFrameworks>net9.0;net8.0</TargetFrameworks>
После 12 ноября 2024 поддерживаемыми платформами останутся:
- .NET 8 (Long Term Support - до 10 ноября 2026)
- .NET 9 (Standard Term Support - 18 месяцев с даты релиза).
5. Соберите проект и устраните проблемы
После того, как вы всё настроите, соберите решение и устраните все возникающие проблемы:
- Проблемы с исходным кодом. Возможно, у вас есть методы, которые будут конфликтовать с новинками .NET 9, например, метод расширения Index для IEnumerable<T>.
- Ошибки/предупреждения зависимостей. .NET 9 SDK более открыто сообщает о пакетах с проблемами безопасности или устаревшими зависимостями. Даже транзитивные зависимости (те, на которые вы не ссылаетесь напрямую) могут вызывать предупреждения. Здесь поможет команда
dotnet nuget why <solution/project folder> <packageid>
Вы можете либо закрепить определённые версии, либо перейти на заменяющие пакеты. Одним из распространённых примеров является System.Text.Json, на старые и устаревшие версии которого ссылаются многие пакеты. Явно добавляя ссылку на пакет, вы закрепляете версию, используемую вашим проектом, например:
<PackageReference Include="System.Text.Json" Version="8.0.4" />
Централизованное управление пакетами — хороший вариант для решения в одном месте для обработки версий пакетов, включая транзитивные.
Итого
Фактически, вы можете начать использовать новый .NET 9 SDK сегодня, продолжая ориентироваться на старые фреймворки и получая доступ к новым функциям времени сборки, оставаясь в текущей среде выполнения. В целом, особых проблем быть не должно.
Источник: https://www.devlead.se/posts/2024/2024-09-22-preparing-for-dotnet-9
👍15
День 2085. #Книги
На днях мне пришла очередная книга, над переводом которой я работал совместно с сообществом DotNetRu. Эндрю Лок «ASP.NET Core в действии» — М.: ДМК Пресс, 2024.
Это уже пятая книга от сообщества DotNet.Ru, над переводом которой я работал. В том числе доводилось поработать и над вторым изданием этой книги. Эндрю Лок - один из лучших специалистов в области ASP.NET Core и очень внимателен к деталям, поэтому над его книгами работать одно удовольствие. Пусть вас не смущает описанная 7я версия фреймворка, все концепции, описанные в книге, сохранились и работают так же, как описано. А примеры из книги вы можете использовать и в более поздних версиях. Книга подойдёт как для совсем новичков, так и для опытных разработчиков, желающих отточить свои навыки и лучше понять, как работает ASP.NET Core изнутри.
На днях мне пришла очередная книга, над переводом которой я работал совместно с сообществом DotNetRu. Эндрю Лок «ASP.NET Core в действии» — М.: ДМК Пресс, 2024.
Это уже пятая книга от сообщества DotNet.Ru, над переводом которой я работал. В том числе доводилось поработать и над вторым изданием этой книги. Эндрю Лок - один из лучших специалистов в области ASP.NET Core и очень внимателен к деталям, поэтому над его книгами работать одно удовольствие. Пусть вас не смущает описанная 7я версия фреймворка, все концепции, описанные в книге, сохранились и работают так же, как описано. А примеры из книги вы можете использовать и в более поздних версиях. Книга подойдёт как для совсем новичков, так и для опытных разработчиков, желающих отточить свои навыки и лучше понять, как работает ASP.NET Core изнутри.
👍50
День 2086. #Docker
Развенчиваем Мифы о Docker. Начало
В 2013м Docker произвёл революцию, представив портативную, удобную для пользователя платформу контейнеров, получившую широкое распространение. Хотя Docker Desktop является ведущим инструментом для создания контейнеризированных приложений, Docker по-прежнему окружён многочисленными заблуждениями. В этой серии развенчаем главные мифы о Docker и рассмотрим его возможности и преимущества.
Миф 1: Docker больше не является продуктом с открытым кодом
Docker состоит из нескольких компонентов, большинство из которых являются продуктами с открытым кодом. Основной Docker Engine и другие важные части экосистемы Docker, такие как Docker CLI и Docker Compose, остаются продуктами с открытым кодом.
В 2017 году из тогдашней монолитной кодовой базы Docker был выделен проект Moby, чтобы предоставить набор «строительных блоков» для создания контейнерных решений и платформ. Docker использует Moby для бесплатного проекта Docker Engine и коммерческого Docker Desktop.
Пользователи также могут найти проверенный контент с открытым кодом на Docker Hub: спонсируемые Docker образы и официальные образы Docker.
Миф 2: Docker-контейнеры — это виртуальные машины
Docker-контейнеры часто ошибочно принимают за виртуальные машины (VM), но эти технологии работают совершенно по-разному. В отличие от VM, Docker-контейнеры не включают в себя всю операционную систему. Они совместно используют ядро операционной системы хоста, что делает их более лёгкими и эффективными. Для виртуальных машин требуется гипервизор для создания виртуального оборудования для гостевой ОС, что приводит к значительным накладным расходам. Docker упаковывает только приложение и его зависимости.
Docker-контейнеры в целом используют меньше ресурсов, чем виртуальные машины, которым требуются значительные ресурсы для одновременного запуска нескольких операционных систем. Docker эффективно запускает множество изолированных приложений на одном хосте, оптимизируя инфраструктуру и рабочие процессы.
Однако при работе на системах, отличных от Linux, Docker должен эмулировать среду Linux. Например, Docker Desktop использует полностью управляемую виртуальную машину для обеспечения единообразной работы в Windows, Mac и Linux, запуская свои компоненты Linux внутри этой виртуальной машины.
Миф 3: Docker Engine, Docker Desktop и Docker Enterprise Edition — одно и то же
Значительная путаница окружает различные доступные варианты Docker, которые включают в себя:
- Mirantis Container Runtime
Docker Enterprise Edition (Docker EE) был продан Mirantis в 2019 году и переименован в Mirantis Container Runtime. Это платное ПО предназначено для развёртывания производственных контейнеров и предлагает легкую альтернативу существующим инструментам оркестровки.
- Docker Engine
Полностью открытая версия, созданная на основе проекта Moby, предоставляющая Docker Engine и CLI.
- Docker Desktop
Коммерческое ПО, продаваемое Docker, которое объединяет Docker Engine с дополнительными функциями для повышения производительности разработчиков. Подписка Docker Business включает расширенные функции безопасности и управления для предприятий.
Эти варианты отличаются в основном функциями и возможностями. Docker Engine обслуживает сообщество разработчиков с открытым кодом, Docker Desktop улучшает рабочие процессы разработчиков с помощью комплексного набора инструментов для создания и масштабирования приложений, а Mirantis Container Runtime предоставляет специализированное решение для корпоративных производственных сред с расширенным управлением и поддержкой.
Продолжение следует…
Источник: https://www.docker.com/blog/docker-myths-debunked/
Развенчиваем Мифы о Docker. Начало
В 2013м Docker произвёл революцию, представив портативную, удобную для пользователя платформу контейнеров, получившую широкое распространение. Хотя Docker Desktop является ведущим инструментом для создания контейнеризированных приложений, Docker по-прежнему окружён многочисленными заблуждениями. В этой серии развенчаем главные мифы о Docker и рассмотрим его возможности и преимущества.
Миф 1: Docker больше не является продуктом с открытым кодом
Docker состоит из нескольких компонентов, большинство из которых являются продуктами с открытым кодом. Основной Docker Engine и другие важные части экосистемы Docker, такие как Docker CLI и Docker Compose, остаются продуктами с открытым кодом.
В 2017 году из тогдашней монолитной кодовой базы Docker был выделен проект Moby, чтобы предоставить набор «строительных блоков» для создания контейнерных решений и платформ. Docker использует Moby для бесплатного проекта Docker Engine и коммерческого Docker Desktop.
Пользователи также могут найти проверенный контент с открытым кодом на Docker Hub: спонсируемые Docker образы и официальные образы Docker.
Миф 2: Docker-контейнеры — это виртуальные машины
Docker-контейнеры часто ошибочно принимают за виртуальные машины (VM), но эти технологии работают совершенно по-разному. В отличие от VM, Docker-контейнеры не включают в себя всю операционную систему. Они совместно используют ядро операционной системы хоста, что делает их более лёгкими и эффективными. Для виртуальных машин требуется гипервизор для создания виртуального оборудования для гостевой ОС, что приводит к значительным накладным расходам. Docker упаковывает только приложение и его зависимости.
Docker-контейнеры в целом используют меньше ресурсов, чем виртуальные машины, которым требуются значительные ресурсы для одновременного запуска нескольких операционных систем. Docker эффективно запускает множество изолированных приложений на одном хосте, оптимизируя инфраструктуру и рабочие процессы.
Однако при работе на системах, отличных от Linux, Docker должен эмулировать среду Linux. Например, Docker Desktop использует полностью управляемую виртуальную машину для обеспечения единообразной работы в Windows, Mac и Linux, запуская свои компоненты Linux внутри этой виртуальной машины.
Миф 3: Docker Engine, Docker Desktop и Docker Enterprise Edition — одно и то же
Значительная путаница окружает различные доступные варианты Docker, которые включают в себя:
- Mirantis Container Runtime
Docker Enterprise Edition (Docker EE) был продан Mirantis в 2019 году и переименован в Mirantis Container Runtime. Это платное ПО предназначено для развёртывания производственных контейнеров и предлагает легкую альтернативу существующим инструментам оркестровки.
- Docker Engine
Полностью открытая версия, созданная на основе проекта Moby, предоставляющая Docker Engine и CLI.
- Docker Desktop
Коммерческое ПО, продаваемое Docker, которое объединяет Docker Engine с дополнительными функциями для повышения производительности разработчиков. Подписка Docker Business включает расширенные функции безопасности и управления для предприятий.
Эти варианты отличаются в основном функциями и возможностями. Docker Engine обслуживает сообщество разработчиков с открытым кодом, Docker Desktop улучшает рабочие процессы разработчиков с помощью комплексного набора инструментов для создания и масштабирования приложений, а Mirantis Container Runtime предоставляет специализированное решение для корпоративных производственных сред с расширенным управлением и поддержкой.
Продолжение следует…
Источник: https://www.docker.com/blog/docker-myths-debunked/
👍12
День 2087. #Docker
Развенчиваем Мифы о Docker. Продолжение
Начало
Миф 4: Docker — то же самое, что Kubernetes
Этот миф возникает из-за того, что и Docker, и Kubernetes связаны с контейнеризированными средами. Но они выполняют разные роли.
Kubernetes (K8s) — система оркестровки для управления экземплярами контейнеров в масштабе. Он автоматизирует развёртывание, масштабирование и эксплуатацию нескольких контейнеров в кластерах хостов. Другие технологии оркестровки включают Nomad, бессерверные фреймворки, режим Swarm в Docker и Apache Mesos. Каждая из них предлагает различные функции для управления контейнеризированными рабочими нагрузками.
Docker — в первую очередь платформа для разработки, доставки и запуска контейнеризированных приложений. Она фокусируется на упаковке приложений и их зависимостей в переносимый контейнер и часто используется для локальной разработки, где масштабирование не требуется. Docker Desktop включает Docker Compose, который предназначен для локального оркестрования многоконтейнерных развёртываний.
Во многих организациях Docker используется для разработки приложений, а полученные образы Docker затем развёртываются в Kubernetes для производства. Для поддержки этого рабочего процесса Docker Desktop включает встроенную установку Kubernetes и инструмент Compose Bridge для перевода формата Compose в код для Kubernetes.
Миф 5: Docker не безопасен
Такое убеждение часто возникает из-за недопонимания того, как реализована безопасность в Docker. Чтобы помочь снизить уязвимости безопасности Docker предлагает следующие меры:
- Конфигурация безопасности по выбору
За исключением нескольких компонентов, Docker работает на основе добровольного включения безопасности. Такой подход устраняет помехи для новых пользователей, но означает, что Docker все равно можно настроить для большей безопасности с точки зрения корпоративных требований и для пользователей, заботящихся о безопасности и имеющих конфиденциальные данные.
- Возможности режима «Rootless»
Docker Engine может работать в режиме rootless, в котором демон Docker работает без прав root. Это уменьшает потенциальный радиус поражения вредоносного кода, покидающего контейнер и получающего права root на хосте. Docker Desktop также предлагает улучшенную изоляцию контейнера (ECI).
- Встроенные функции безопасности
Также Docker включает встроенные функции, такие как пространства имен, группы управления (cgroups) и профили seccomp, которые обеспечивают изоляцию и ограничивают возможности контейнеров.
- Аттестация SOC 2 Type 2 и сертификация ISO 27001
Как инструмент с открытым исходным кодом Docker Engine не подпадает под эти сертификации. Они относятся к платным продуктам Docker, Inc., которые предлагают дополнительные функции безопасности корпоративного уровня.
Docker также предоставляет документацию и учебные материалы, призванные помочь пользователям научиться эффективно защищать свои контейнеры.
Миф 6: Docker мёртв
Этот миф проистекает из быстрого роста и изменений в экосистеме контейнеров за последнее десятилетие. Docker активно разрабатывается и также широко применяется. Docker Hub - одно из крупнейших в мире хранилищ образов контейнеров.
С развитием науки о данных и AI/ML образы Docker облегчают обмен моделями и приложениями, и поддерживаются возможностями рабочей нагрузки GPU в Docker Desktop. Кроме того, Docker широко используется для быстрого и экономически эффективного макетирования тестовых сценариев в качестве альтернативы развёртыванию реального оборудования или виртуальных машин.
Окончание следует…
Источник: https://www.docker.com/blog/docker-myths-debunked/
Развенчиваем Мифы о Docker. Продолжение
Начало
Миф 4: Docker — то же самое, что Kubernetes
Этот миф возникает из-за того, что и Docker, и Kubernetes связаны с контейнеризированными средами. Но они выполняют разные роли.
Kubernetes (K8s) — система оркестровки для управления экземплярами контейнеров в масштабе. Он автоматизирует развёртывание, масштабирование и эксплуатацию нескольких контейнеров в кластерах хостов. Другие технологии оркестровки включают Nomad, бессерверные фреймворки, режим Swarm в Docker и Apache Mesos. Каждая из них предлагает различные функции для управления контейнеризированными рабочими нагрузками.
Docker — в первую очередь платформа для разработки, доставки и запуска контейнеризированных приложений. Она фокусируется на упаковке приложений и их зависимостей в переносимый контейнер и часто используется для локальной разработки, где масштабирование не требуется. Docker Desktop включает Docker Compose, который предназначен для локального оркестрования многоконтейнерных развёртываний.
Во многих организациях Docker используется для разработки приложений, а полученные образы Docker затем развёртываются в Kubernetes для производства. Для поддержки этого рабочего процесса Docker Desktop включает встроенную установку Kubernetes и инструмент Compose Bridge для перевода формата Compose в код для Kubernetes.
Миф 5: Docker не безопасен
Такое убеждение часто возникает из-за недопонимания того, как реализована безопасность в Docker. Чтобы помочь снизить уязвимости безопасности Docker предлагает следующие меры:
- Конфигурация безопасности по выбору
За исключением нескольких компонентов, Docker работает на основе добровольного включения безопасности. Такой подход устраняет помехи для новых пользователей, но означает, что Docker все равно можно настроить для большей безопасности с точки зрения корпоративных требований и для пользователей, заботящихся о безопасности и имеющих конфиденциальные данные.
- Возможности режима «Rootless»
Docker Engine может работать в режиме rootless, в котором демон Docker работает без прав root. Это уменьшает потенциальный радиус поражения вредоносного кода, покидающего контейнер и получающего права root на хосте. Docker Desktop также предлагает улучшенную изоляцию контейнера (ECI).
- Встроенные функции безопасности
Также Docker включает встроенные функции, такие как пространства имен, группы управления (cgroups) и профили seccomp, которые обеспечивают изоляцию и ограничивают возможности контейнеров.
- Аттестация SOC 2 Type 2 и сертификация ISO 27001
Как инструмент с открытым исходным кодом Docker Engine не подпадает под эти сертификации. Они относятся к платным продуктам Docker, Inc., которые предлагают дополнительные функции безопасности корпоративного уровня.
Docker также предоставляет документацию и учебные материалы, призванные помочь пользователям научиться эффективно защищать свои контейнеры.
Миф 6: Docker мёртв
Этот миф проистекает из быстрого роста и изменений в экосистеме контейнеров за последнее десятилетие. Docker активно разрабатывается и также широко применяется. Docker Hub - одно из крупнейших в мире хранилищ образов контейнеров.
С развитием науки о данных и AI/ML образы Docker облегчают обмен моделями и приложениями, и поддерживаются возможностями рабочей нагрузки GPU в Docker Desktop. Кроме того, Docker широко используется для быстрого и экономически эффективного макетирования тестовых сценариев в качестве альтернативы развёртыванию реального оборудования или виртуальных машин.
Окончание следует…
Источник: https://www.docker.com/blog/docker-myths-debunked/
👍9
День 2088. #Docker
Развенчиваем Мифы о Docker. Окончание
Начало
Продолжение
Миф 7: Docker сложно изучить
Такое мнение часто возникает из-за предполагаемой сложности концепций контейнеров и многочисленных функций Docker. Однако Docker является популярной технологией, используемой более чем 20 миллионами разработчиков по всему миру, и доступно бесчисленное множество ресурсов, чтобы сделать изучение Docker доступным.
Docker, Inc. стремится создавать интуитивно понятный и удобный дизайн для Docker Desktop и вспомогательных продуктов. Документация, семинары, тренинги, руководства и примеры доступны на сайте Docker Desktop, в блогах, а также в подписках на новости. А курсы Udemy, созданные совместно с Docker, помогают новым пользователям понять контейнеризацию и использование Docker.
Миф № 8: Docker и контейнеры предназначены только для разработчиков
Docker и контейнеры используются в различных областях, помимо разработки:
- Data science
Docker предоставляет согласованные среды, позволяя специалистам по данным беспрепятственно обмениваться моделями, наборами данных и настройками разработки.
- Здравоохранение
Docker развёртывает масштабируемые приложения для управления данными пациентов и запуска симуляций, таких как ПО для медицинской визуализации, в различных больничных системах.
- Образование
Преподаватели и студенты используют Docker для создания воспроизводимых «песочниц», которые облегчают совместную работу и упрощают настройки проектов кодирования.
Универсальность Docker выходит за рамки разработки, предоставляя согласованные, масштабируемые и безопасные среды для различных приложений.
Миф № 9: Docker Desktop — всего лишь графический интерфейс
Этот миф игнорирует его обширные функции, разработанные для улучшения опыта разработчиков, упрощения управления контейнерами и повышения производительности:
- Поддержка кроссплатформенности
Docker работает на базе Linux, но большинство рабочих станций разработчиков работают под управлением Windows или macOS. Docker Desktop позволяет этим платформам запускать инструменты Docker внутри полностью управляемой виртуальной машины, интегрированной с сетями, файловой системой и ресурсами хост-системы.
- Инструменты разработчика
Встроенные Kubernetes, Docker Scout для управления цепочкой поставок, Docker Build Cloud для более быстрой сборки и Docker Debug для отладки контейнеров.
- Безопасность и управление
Для администраторов Docker Desktop предлагает управление доступом к реестру и к образам, улучшенную изоляцию контейнеров, единый вход (SSO) для авторизации и управление настройками, и т.д.
Миф 10: Контейнеры предназначены только для микросервисов
Контейнеры популярны для архитектур микросервисов, но их можно использовать для любого типа приложений. Монолитные приложения можно контейнеризировать, что позволяет изолировать их и их зависимости в образ с версиями, которые могут работать в разных средах. Это позволяет при желании проводить постепенный рефакторинг в микросервисы.
Кроме того, Docker отлично подходит для быстрого прототипирования, позволяя быстро развёртывать минимально жизнеспособные продукты (MVP). Контейнеризованные прототипы проще в управлении и рефакторинге по сравнению с теми, которые развёрнуты на виртуальных машинах или на голом железе.
Итого
Docker может значительно повысить производительность, масштабируемость и безопасность для различных вариантов использования. Универсальность Docker в сочетании с обширными учебными ресурсами и надёжными функциями безопасности делает его незаменимым инструментом в современной разработке и развёртывании ПО.
Источник: https://www.docker.com/blog/docker-myths-debunked/
Развенчиваем Мифы о Docker. Окончание
Начало
Продолжение
Миф 7: Docker сложно изучить
Такое мнение часто возникает из-за предполагаемой сложности концепций контейнеров и многочисленных функций Docker. Однако Docker является популярной технологией, используемой более чем 20 миллионами разработчиков по всему миру, и доступно бесчисленное множество ресурсов, чтобы сделать изучение Docker доступным.
Docker, Inc. стремится создавать интуитивно понятный и удобный дизайн для Docker Desktop и вспомогательных продуктов. Документация, семинары, тренинги, руководства и примеры доступны на сайте Docker Desktop, в блогах, а также в подписках на новости. А курсы Udemy, созданные совместно с Docker, помогают новым пользователям понять контейнеризацию и использование Docker.
Миф № 8: Docker и контейнеры предназначены только для разработчиков
Docker и контейнеры используются в различных областях, помимо разработки:
- Data science
Docker предоставляет согласованные среды, позволяя специалистам по данным беспрепятственно обмениваться моделями, наборами данных и настройками разработки.
- Здравоохранение
Docker развёртывает масштабируемые приложения для управления данными пациентов и запуска симуляций, таких как ПО для медицинской визуализации, в различных больничных системах.
- Образование
Преподаватели и студенты используют Docker для создания воспроизводимых «песочниц», которые облегчают совместную работу и упрощают настройки проектов кодирования.
Универсальность Docker выходит за рамки разработки, предоставляя согласованные, масштабируемые и безопасные среды для различных приложений.
Миф № 9: Docker Desktop — всего лишь графический интерфейс
Этот миф игнорирует его обширные функции, разработанные для улучшения опыта разработчиков, упрощения управления контейнерами и повышения производительности:
- Поддержка кроссплатформенности
Docker работает на базе Linux, но большинство рабочих станций разработчиков работают под управлением Windows или macOS. Docker Desktop позволяет этим платформам запускать инструменты Docker внутри полностью управляемой виртуальной машины, интегрированной с сетями, файловой системой и ресурсами хост-системы.
- Инструменты разработчика
Встроенные Kubernetes, Docker Scout для управления цепочкой поставок, Docker Build Cloud для более быстрой сборки и Docker Debug для отладки контейнеров.
- Безопасность и управление
Для администраторов Docker Desktop предлагает управление доступом к реестру и к образам, улучшенную изоляцию контейнеров, единый вход (SSO) для авторизации и управление настройками, и т.д.
Миф 10: Контейнеры предназначены только для микросервисов
Контейнеры популярны для архитектур микросервисов, но их можно использовать для любого типа приложений. Монолитные приложения можно контейнеризировать, что позволяет изолировать их и их зависимости в образ с версиями, которые могут работать в разных средах. Это позволяет при желании проводить постепенный рефакторинг в микросервисы.
Кроме того, Docker отлично подходит для быстрого прототипирования, позволяя быстро развёртывать минимально жизнеспособные продукты (MVP). Контейнеризованные прототипы проще в управлении и рефакторинге по сравнению с теми, которые развёрнуты на виртуальных машинах или на голом железе.
Итого
Docker может значительно повысить производительность, масштабируемость и безопасность для различных вариантов использования. Универсальность Docker в сочетании с обширными учебными ресурсами и надёжными функциями безопасности делает его незаменимым инструментом в современной разработке и развёртывании ПО.
Источник: https://www.docker.com/blog/docker-myths-debunked/
👍15
День 2089. #УрокиРазработки
Уроки 50 Лет Разработки ПО
Урок 28. Не меняйте оценку в зависимости от того, что хочет услышать получатель
Предположим, клиент спрашивает, сколько времени вам потребуется, чтобы завершить следующую часть вашего проекта. Основываясь на анализе прошлого опыта, вы отвечаете: «Около двух месяцев».
«Два месяца? — усмехается клиент. — Моя 12-летняя дочь сделает это за три недели!»
В ответ вы, сопротивляясь искушению предложить ему нанять свою дочь, делаете вторую попытку: «Хорошо, как насчет одного месяца?»
Что изменилось за эти несколько секунд? Задача не уменьшилась. Вы не стали более продуктивным. У вас не появился вдруг добровольный помощник, готовый помочь выполнить работу. Просто клиенту не понравился ваш первый ответ, и вы предложили альтернативу, кажущуюся более привлекательной. Если ваша оценка и ожидания заказчика слишком расходятся, то вам придётся провести переговоры, чтобы прийти к какому-либо соглашению. Однако нет никаких оснований изменять продуманную оценку только потому, что она кому-то не понравилась.
Оценка — это предсказание будущего. Мы основываем оценки на том, что известно о текущей задаче, на предыдущем опыте решения аналогичных задач и некоторых предположениях. Особо дотошные могут также принять во внимание любые неподконтрольные им факторы, возможные риски, потенциальные изменения в постановке задачи и неопределённость, которая может повлиять на планы. Чем меньше мы знаем обо всех этих факторах, тем ниже вероятность, что оценка будет соответствовать реальному положению дел. Кто-то другой, учитывающий иной набор параметров, может получить совсем иную оценку времени выполнения той же работы.
Цели и оценки
Важно отличать оценки от целей. Допустим, разработчик обсуждает новый проект со старшим менеджером. Продолжительность проекта, по оценке разработчика, в 4 раза превышает ожидания менеджера. Но, уступив давлению менеджера, разработчик соглашается на гораздо более короткий срок, даже при том, что уложиться в него нет никакой возможности.
Более рациональным подходом для разработчика было бы сказать: «Я пришёл к своей оценке согласно таким-то и таким-то расчётам. А как вы получили свою?» Скорей всего, у менеджера не было никакой оценки — у него была цель. У разработчика тоже не было оценки — у было предположение. Цель и предположение оказались далеки друг от друга. Если бы одна из двух сторон разработала верную оценку, то они могли бы быть ближе друг к другу. Вместо этого обсуждение превратилось в напряжённый спор, и человек, обладавший большей властью, выиграл его, получив обещание от другого.
Когда корректировать оценку
Ваша оценка не должна зависеть от того, что хочет услышать заказчик. Тем не менее иногда имеет смысл изменить оценку или, говоря точнее, выполнить переоценку:
- если обнаружится, что предположение или часть информации были неверными;
- после начала работы, когда вы лучше поймёте задачу;
- когда объём работы изменится;
- если обнаружится, что вы продвигаетесь быстрее, чем ожидали (такое случается);
- когда меняются условия, например люди, работающие над проектом;
- когда исчезнут риски или пропадёт зависимость.
Если не произойдёт каких-либо изменений, подобных этим, то не следует изменять прогноз. Если ваша оценка не совпадает с чьими-то целями, ожиданиями или ограничениями, то вы должны совместно исследовать это расхождение. Не следует оставлять конфликт неразрешённым. Вы можете подвергнуть сомнению свои предположения, обсудить риски и попробовать альтернативные методы расчётов, чтобы подтвердить или опровергнуть оценку. Возможно, исходные данные, на которые вы опирались, плохо подходят для оценки рассматриваемой работы. Вы можете договориться об объёме, ресурсах или качестве, чтобы увидеть, получится ли более приемлемая оценка. Но если ваша оценка получена в результате тщательного анализа, то не уступайте просто ради того, чтобы кому-то угодить. Люди перестанут доверять вашим прогнозам, зная, что могут изменить их, оказав достаточное давление.
Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 4.
Уроки 50 Лет Разработки ПО
Урок 28. Не меняйте оценку в зависимости от того, что хочет услышать получатель
Предположим, клиент спрашивает, сколько времени вам потребуется, чтобы завершить следующую часть вашего проекта. Основываясь на анализе прошлого опыта, вы отвечаете: «Около двух месяцев».
«Два месяца? — усмехается клиент. — Моя 12-летняя дочь сделает это за три недели!»
В ответ вы, сопротивляясь искушению предложить ему нанять свою дочь, делаете вторую попытку: «Хорошо, как насчет одного месяца?»
Что изменилось за эти несколько секунд? Задача не уменьшилась. Вы не стали более продуктивным. У вас не появился вдруг добровольный помощник, готовый помочь выполнить работу. Просто клиенту не понравился ваш первый ответ, и вы предложили альтернативу, кажущуюся более привлекательной. Если ваша оценка и ожидания заказчика слишком расходятся, то вам придётся провести переговоры, чтобы прийти к какому-либо соглашению. Однако нет никаких оснований изменять продуманную оценку только потому, что она кому-то не понравилась.
Оценка — это предсказание будущего. Мы основываем оценки на том, что известно о текущей задаче, на предыдущем опыте решения аналогичных задач и некоторых предположениях. Особо дотошные могут также принять во внимание любые неподконтрольные им факторы, возможные риски, потенциальные изменения в постановке задачи и неопределённость, которая может повлиять на планы. Чем меньше мы знаем обо всех этих факторах, тем ниже вероятность, что оценка будет соответствовать реальному положению дел. Кто-то другой, учитывающий иной набор параметров, может получить совсем иную оценку времени выполнения той же работы.
Цели и оценки
Важно отличать оценки от целей. Допустим, разработчик обсуждает новый проект со старшим менеджером. Продолжительность проекта, по оценке разработчика, в 4 раза превышает ожидания менеджера. Но, уступив давлению менеджера, разработчик соглашается на гораздо более короткий срок, даже при том, что уложиться в него нет никакой возможности.
Более рациональным подходом для разработчика было бы сказать: «Я пришёл к своей оценке согласно таким-то и таким-то расчётам. А как вы получили свою?» Скорей всего, у менеджера не было никакой оценки — у него была цель. У разработчика тоже не было оценки — у было предположение. Цель и предположение оказались далеки друг от друга. Если бы одна из двух сторон разработала верную оценку, то они могли бы быть ближе друг к другу. Вместо этого обсуждение превратилось в напряжённый спор, и человек, обладавший большей властью, выиграл его, получив обещание от другого.
Когда корректировать оценку
Ваша оценка не должна зависеть от того, что хочет услышать заказчик. Тем не менее иногда имеет смысл изменить оценку или, говоря точнее, выполнить переоценку:
- если обнаружится, что предположение или часть информации были неверными;
- после начала работы, когда вы лучше поймёте задачу;
- когда объём работы изменится;
- если обнаружится, что вы продвигаетесь быстрее, чем ожидали (такое случается);
- когда меняются условия, например люди, работающие над проектом;
- когда исчезнут риски или пропадёт зависимость.
Если не произойдёт каких-либо изменений, подобных этим, то не следует изменять прогноз. Если ваша оценка не совпадает с чьими-то целями, ожиданиями или ограничениями, то вы должны совместно исследовать это расхождение. Не следует оставлять конфликт неразрешённым. Вы можете подвергнуть сомнению свои предположения, обсудить риски и попробовать альтернативные методы расчётов, чтобы подтвердить или опровергнуть оценку. Возможно, исходные данные, на которые вы опирались, плохо подходят для оценки рассматриваемой работы. Вы можете договориться об объёме, ресурсах или качестве, чтобы увидеть, получится ли более приемлемая оценка. Но если ваша оценка получена в результате тщательного анализа, то не уступайте просто ради того, чтобы кому-то угодить. Люди перестанут доверять вашим прогнозам, зная, что могут изменить их, оказав достаточное давление.
Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 4.
👍13