Привет, Хабр! Представляю вашему вниманию перевод статьи SQL Server Insert Performance for Clustered Indexes vs. Heap Tables

Вопрос

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

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

Mark Seeman расскажет о функциональном программировании просто и быстро. Для этого он начал писать цикл статей, посвященных связи между паттернами проектирования и теорией категорий. Любой ООПшник, у которого есть 15 минут свободного времени, сможет заполучить в свои руки принципиально новый набор идей и инсайтов, касающихся не только функциональщины, но и правильного объектно-ориентированного дизайна. Решающим фактором является то, что все примеры — это реальный код на C#, F# и Haskell. Этот хабрапост — перевод самого начала цикла, первых трех статей, слитых воедино для удобства понимания.

Кроме того, с Марком можно пообщаться вживую, посетив конференцию DotNext 2017 Moscow, которая состоится 12-13 ноября 2017 г. в Москве, в «Славянская Рэдиссон». Марк прочитает доклад на тему «From dependency injection to dependency rejection». Билеты можно взять здесь.

Практики управления техническим долгом в отдельно взятой команде

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

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

Что удалось получить в результате:

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

Давайте расскажу, как мы этого добились.

Перевод статьи Vincent Driessen: A successful Git branching model

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



В качестве инструмента управления версиями всего исходного кода она использует Git.

На хабре уже было много статей о распределенных системах управления версиями (DVCS), их сравнений, а также сравнений GUI-клиентов для них. Также были обсуждения плагинов к IDE для работы с git и mercurial. Но практически не было информации об инструментах визуального сравнения и разрешения конфликтов слияния.


Недавно я «перескочил» с mercurial (который до сих пор считаю более удобным и логичным) на git, потому что, подавляющее большинство проектов, которые мне интересны, используют git и хостятся на github. В связи с этим, встал вопрос о пересмотре арсенала инструментов, в частности вопрос выбора инструмента визуального сравнения и слияния (diff and merge). Дабы восполнить недостаток информации на хабре, я решил написать этот мини-обзор. Как говориться — по горячим следам.

Под катом Вы также найдете примеры настроек Git для использования с DiffMerge и WinMerge под Windows. Думаю многим сэкономит время.

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

Я постараюсь донести основные идеи, показать как эта VCS помогает разрабатывать проект. Надеюсь, что после прочтения вы сможете ответить на вопросы:

• можно ли git «подстроить» под тот процесс разработки, который мне нужен?
• будет ли менеджер и заказчик удовлетворён этим процессом?
• будет ли легко работать разработчикам?
• смогут ли новички быстро включиться в процесс?
• можно ли процесс относительно легко и быстро изменить?

Конечно, я попытаюсь рассказать обо всём по-порядку, начиная с основ. Поэтому, эта статья будет крайне полезна тем, кто только начинает или хочет разобраться с git. Более опытные читатели, возможно, найдут для себя что-то новое, укажут на ошибки или поделятся советом.

Rebase — один из двух способов объединить изменения, сделанные в одной ветке, с другой веткой. Начинающие и даже опытные пользователи git иногда испытывают нежелание пользоваться ей, так как не видят смысла осваивать еще один способ объединять изменения, когда уже и так прекрасно владеют операцией merge. В этой статье я бы хотел подробно разобрать теорию и практику использования rebase.

Теория

Итак, освежим теоретические знания о том, что же такое rebase. Для начала вкратце — у вас есть две ветки — master и feature, обе локальные, feature была создана от master в состоянии A и содержит в себе коммиты C, D и E. В ветку master после отделения от нее ветки feature был сделан 1 коммит B.

Реляционные базы данных (РБД) используются повсюду. Они бывают самых разных видов, от маленьких и полезных SQLite до мощных Teradata. Но в то же время существует очень немного статей, объясняющих принцип действия и устройство реляционных баз данных. Да и те, что есть — довольно поверхностные, без особых подробностей. Зато по более «модным» направлениям (большие данные, NoSQL или JS) написано гораздо больше статей, причём куда более глубоких. Вероятно, такая ситуация сложилась из-за того, что реляционные БД — вещь «старая» и слишком скучная, чтобы разбирать её вне университетских программ, исследовательских работ и книг.

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

От переводчика: некоторые скорее всего уже читали этот титанический труд от Мартина Фаулера и его коллеги Джеймса Льюиса, но я все же решил сделать перевод этой статьи. Тренд микросервисов набирает обороты в мире enterprise разработки, и эта статья является ценнейшим источником знаний, по сути выжимкой существующего опыта работы с ними.

Термин «Microservice Architecture» получил распространение в последние несколько лет как описание способа дизайна приложений в виде набора независимо развертываемых сервисов. В то время как нет точного описания этого архитектурного стиля, существует некий общий набор характеристик: организация сервисов вокруг бизнес-потребностей, автоматическое развертывание, перенос логики от шины сообщений к приемникам (endpoints) и децентрализованный контроль над языками и данными.

Практически все проекты сталкиваются с проблемами, вызванными неправильной обработкой и хранением даты и времени. Даже если проект используется в одном часовом поясе, все равно после перехода на зимнее/летнее время можно получить неприятные неожиданности. При этом мало кто озадачивается реализацией правильного механизма со старта, потому что кажется, что с этим проблем быть не может, так как все тривиально. К сожалению, в последствии реальность показывает, что это не так.

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

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

По роду деятельности студентом мне часто приходится писать различные лабораторные и курсовые работы. Неотъемлемая часть этих работ(как и в 80% задач бизнес-программирования) — код составления отчета о найденных элементах в базе данных или выполненной длительной и сложной операции. В десктопном программировании в рамках .NET Framework есть различные способы решения подобных проблем:

• Старая школа: формат RTF никто не отменял, однако вручную составить что-либо сложнее цветного текста со шрифтами разного цвета и ссылками лично у меня не получалось. Способ действенный, но стандарт не самый легкий для понимания, на последнюю версию даже смотреть страшно
• Для Silverlight/WPF — формирование FlowDocument своими руками. Объектная модель однозначно удобнее формирования старого формата вручную, но вариант тоже только для смелых
• Сторонние решения вроде Crystal Reports, возможно и очень мощный инструмент для создания отчетов, но не всегда в этом есть необходимость, к тому же не всегда есть возможность тянуть пару-тройку дополнительных программных продуктов¹
• Использование Microsoft Office Interop. Нет, это издевательство. Ручная работа с памятью в управляемой среде вызывает лишь бурю радости. Начинающий программист выпьет не одну упаковку кофе, прежде чем смирится с подобным принципом работы.
• Формирование HTML. На нашу радость, стандарт позволяет создать документы средней степени форматированности, с помощью CSS можно довести до ума. Минусы — оформить документ по всем требованиям крайне затруднительно. Но это если в этом есть необходимость. Плюсы: простота стандарта и всеобщий переход «в облака и браузеры» стимулирует развитие HTML.

О последнем я и буду вести речь.

Тема отличий таких понятий как Entity (Сущность) и Value Object (Объект-Значение) из Domain-Driven Design не нова. Тем не менее, я не смог найти статью с полным списком их отличий, так что решил написать свою.

Распределенные системы контроля версий (DVCS) постепенно замещают собой централизованные. Если вы еще не используете одну из них — самое время попробовать.

В статье я постараюсь показать, как можно быстро начать экспериментировать с git, используя сайт github.com.

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

Привет, хаброразработчик!
Нет, это не очередной конкурс спали клавиатуру А и получи клавиатуру Г. Сегодня мы поговорим о горячих клавишах в Visual Studio 2008.

Итак, вы новичок в WPF или Silverlight и желаете знать с чего вам начать? Здесь описан мой путь изучения “Как начать с WPF и Silverlight”. Я предполагаю, что вы знаете что из себя представляют эти технологии (на высоком уровне), но не знаете как использовать их.

Итоговый выпуск иконок

Пять лет тому назад мы начали рисовать набор пиксельных иконок. Мода была на Vista. К концу 2013 года набор FatCow дорос до 3926 иконок. Это на 356 иконок больше, чем у Fugue, который весной того же года остановился на цифре 3570 (размер: 16х16). 352 иконки из бонуса Fugue (32х32 и 24х24) не в счет (как повторы). Но дальнейшее развитие иконок FatCow заморожено. Увы, мы не увидим круглой цифры из 4000 иконок (работы осталось на месяц), не увидим выпуска для ретины дополнительных размеров уже существующих иконок, разработки прекращены из-за отсутствия бюджета. Успели сделать пробу для retina и только.

Да, это не мега-фото-реалистичные-3D еще-одни-никому-не-нужные-иконки, это старая пиксельная школа. Где в почете был маленький размер и ограничение цветовой гаммы. Пройдут еще 10 лет… и, мы искренне верим, пиксельные иконки так и останутся в ходу. И если Вы ценитель древних видов искусства, дней зарождения компьютерной графики, пожалуйста за ширмой!

Когда обобщения(generic) пришли к нам вместе с C# 2.0, они стали одной из лучших возможностей в этом языке. Те, кто когда-либо создавал классы строготипизированных коллекций в C# 1.0 знает, насколько они упростили нам жизнь и уменьшили количество кода. Единственная проблема заключалась в том, что обобщенные типы не следовали тем же правилам наследования, которые были в силе для обычных типов.

Приветствую, Хабр!

Эта статья продолжит тему автоматической кодогенерации в Visual Studio с помощью T4 — Text Template Transformation Toolkit. Часть №1, чуть ранее опубликованная в этом блоге, описывала синтаксис T4 и элементарные принципы его использования. В этот же раз я решил подробнее осмотреть блог уважаемого Олега Сыча и ещё немного адаптировать к хабрааудитории некоторые из его наработок. В частности, сегодня обсудим следующие темы:

• Создание повторно используемых и параметризируемых шаблонов
• Создание генераторов шаблонов
• Отладка, тестирование и расширение генераторов (ссылки)

Я не стал изобретать каких-то особенных примеров. История развития запроса с созданием хранимой процедуры, описанная Олегом, идеально подходит для иллюстрации проблемы, при которой могут потребоваться генераторы. Причем, что характерно, — не надуманной проблемы. Также статья придерживается принципа «меньше слов — больше кода».
Здесь и далее предполагается, что у вас установлена Visual Studio 2005/2008/2010, а также T4 Toolbox.

Прочитав статью об изучении MVC и увидев комментарий пользователя RouR, я очень заинтересовался данной темой, ну и на ходу решил перевести указанную им оригинальную статью.

Если и тебе, дорогой хабражитель, это интересно — прошу под кат!

«Я попробую показать вам, что нового несет в себе C# 5.0 с точки зрения асинхронного программирования при использовании ключевого слова await. Особенно для веб-приложений ASP.NET MVC 4.»