Индексы — это первое, что необходимо хорошо понимать в работе SQL Server, но странным образом базовые вопросы не слишком часто задаются на форумах и получают не так уж много ответов.
Роб Шелдон отвечает на эти, вызывающие смущение в профессиональных кругах, вопросы об индексах в SQL Server: одни из них мы просто стесняемся задать, а прежде чем задать другие сначала подумаем дважды.

Недостаточно писать код хорошо читаемым: он также должен быстро выполняться.

Существует три базовых правила для написания такого T-SQL кода, который будет работать хорошо. Они кумулятивные – выполнение всех этих правил окажет положительное влияние на код. Пропуск или изменение любого из них – скорее всего приведет к отрицательному влиянию на производительность вашего кода.

• Пишите, исходя из структуры хранения данных: если вы храните данные типа datetime, используйте именно datetime, а не varchar или что-нибудь еще.
• Пишите, исходя из наличия индексов: если на таблице построены индексы, и они должны там быть, пишите код так, чтобы он мог использовать все преимущества, предоставляемые этими индексами. Убедитесь, что кластерный индекс, а для каждой таблицы он может быть только один, используется наиболее эффективным образом.
• Пишите так, чтобы помочь оптимизатору запросов: оптимизатор запросов – восхитительная часть СУБД. К сожалению, вы можете сильно затруднить ему работу, написав запрос, который ему «тяжело» будет разбирать, например, содержащий вложенные представления – когда одно представление получает данные из другого, а то из третьего – и так далее. Потратьте свое время для того, чтобы понять как работает оптимизатор и писать запросы таким образом, чтобы он мог вам помочь, а не навредить.

Существует несколько типичных ошибок, которые люди допускают в своем коде на T-SQL – не совершайте их.

Как проверить идеи, архитектуру и алгоритмы без написания кода? Как сформулировать и проверить их свойства? Что такое model-checkers и model-finders? Требования и спецификации — пережиток прошлого?

Привет. Меня зовут Васил Дядов, сейчас я работаю программистом в Яндексе, до этого работал в Intel, ещё раньше разрабатывал RTL-код (register transfer level) на Verilog/VHDL для ASIC/FPGA. Давно увлекаюсь темой надёжности софта и аппаратуры, математикой, инструментами и методами, применяемыми для разработки ПО и логики с гарантированными, заранее определёнными свойствами.

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

Не буду лукавить: основная задача статьи — возбудить интерес. Так что в ней будет минимум пространных рассуждений и максимум конкретики.

Бытует мнение, что накладные расходы на вызов методов и организацию процесса выполнения не должны превышать 15% времени выполнения приложения, иначе стоит серьезно задуматься над вопросом рефакторинга приложения и оптимизации его логики. Вооружившись такими мыслями я наткнулся на метод QuickSort из стандартного класса ArraySortHelper<T> использующийся для сортировки массивов в .Net.

Интересным моментом здесь является сравнение элементов — для обеспечения гибкости его вынеслив отдельный класс реализующий интерфейс IComparer<T>. Вооружившись разнообразными мыслями и студией было решено оценить сколько же такая гибкость стоит и что с этим можно было бы сделать — под катом анализ затрат на сравнение элементов во временя работы QuickSort.

Представляю вашему вниманию перевод документа "Coding Guidelines for C# 3.0, 4.0 and 5.0".

Целью создания этого списка правил является попытка установить стандарты написания кода на C#, которые были бы удобными и практичными одновременно. Само собой, мы практикуем то, что создали. Эти правила являются одним из тех стандартов, которые лежат в основе нашей ежедневной работы в AvivaSolutions. Не все эти правила имеют четкое обоснование. Некоторые из них просто приняты у нас в качестве стандартов.

Статический анализатор кода VisualStudio (который также известен как FxComp) и StyleCop могут автоматически применять многие из правил кодирования и оформления путем анализа скомпилированных сборок. Вы можете сконфигурировать их таким образом, чтобы анализ производился во время компиляции или был неотъемлемой частью непрерывной или ежедневной сборки. Этот документ просто добавляет дополнительные правила и рекомендации, но его вспомогательный сайт www.csharpcodingguidelines.com предоставляет список правил анализа кода, необходимых в зависимости от того, с какой базой кода вы работаете.

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

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

• Работа с поставщиками. Чтобы продать что-то ненужное, нужно сначала купить что-то ненужное.
• Управление каталогом. У кого-то узкая специализация, а кто-то продает сотни тысяч разных товаров.
• Управление розничными ценами. Тут придется учесть и цены поставщиков, и цены конкурентов, и доступные финансовые инструменты.
• Работа со складом. В принципе, можно и не иметь собственного склада, а забирать товар со складов партнеров, но так или иначе вопрос стоит.
• Маркетинг. Тут наполнение сайта контентом, размещение на площадках, реклама (онлайн и офлайн), акции и много чего еще.
• Прием и обработка заказов. Колл-центр, корзина на сайте, заказы через мессенджеры, заказы через площадки и маркетплейсы.
• Доставка.
• Бухгалтерия и прочие внутренние системы.

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

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

Так что рассматриваем отдельную систему, более-менее универсальную, с которой интегрирована остальная инфраструктура компании.

Я уже 12 лет создаю различные веб-сервисы и мобильные приложения. И миллион раз я советовал людям делать MVP. Но я чувствую, что нужно быть очень осторожным с этим советом, нужно допускать множество оговорок, когда даешь этот совет и объяснять, что же такое "M" и "V" в этой аббревиатуре.

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

Но многие люди даже после запуска не отпускают эту идею. Думая о том, что теперь это их кредо на всю оставшуюся жизнь.

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

Давайте начнем с простого… Эти запросы отличаются чем-то друг от друга с точки зрения конечного результата?

SELECT COUNT(*) FROM Sales.SalesOrderDetail
SELECT COUNT_BIG(*) FROM Sales.SalesOrderDetail

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

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

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

В интернете мне доводилось слышать множество гневных комментариев в стиле «Да Windows 7 — полный отстой! Вы посмотрите, как она жрет память!» В доказательство приводятся скриншоты вроде того, что ниже, и опять же — все списывается на «криворуких индусских программистов». Давайте посмотрим, насколько эти наезды на программистов Microsoft обоснованы.

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

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

Совсем недавно где-то на Хабре промелькнуло высказывание из серии «Не думал, что консоль в Виндах что-то может. Хотелось бы узнать об этом побольше».

Вот так и возникло желание написать небольшую статью про основные возможности консоли.

Привет, Хабр! Предлагаю вашему вниманию перевод статьи «Top 20 C++ multithreading mistakes and how to avoid them» автора Deb Haldar.


Сцена из фильма «Петля времени» (2012)

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

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

19 сентября в Москве состоялся первый тематический митап HUG (Highload++ User Group), который был посвящён микросервисам. На нём прозвучал доклад «Эксплуатация микросервисов: размер имеет значение, даже если у вас Kubernetes», в котором мы поделились обширным опытом компании «Флант» в области эксплуатации проектов с микросервисной архитектурой. В первую очередь он будет полезен всем разработчикам, задумывающимся о применении этого подхода в своём настоящем или будущем проекте.



Представляем видео с докладом (50 минут, гораздо информативнее статьи), а также основную выжимку из него в текстовом виде.

NB: Видео и презентация доступны также в конце этой публикации.

Недавно прочитал пост о UDP и C# async/await, в котором описание решения несложной задачи по опросу устройств по UDP одним клиентом. Решение задачи с помощью async\await действительно сокращает объем кода, по сравнению с ручной реализацией асинхронных вызовов. С другой стороны создает много проблем с синхронизацией задач, конкурентным доступом к данным и обработкой исключений. Полученное решение очень подвержено ошибкам. Первоначальная версия автора содержала ошибки неосвобождения ресурсов.

Можно ли сделать проще и надежнее?

Автор: Вячеслав Михайлов, Solutions Architect

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

Мы разберемся с процессом аутентификации пользователя, работой технологии единого входа (Single sign-on/SSO), дадим общее представлении о технологии OAuth2 и принципах ее работы, не углубляясь в особенности конкретной технической реализации. В следующей статье в качестве примера удачной реализации мы рассмотрим библиотеку Thinktecture Identity Server v3, подробнее остановимся на ее функциональных возможностях, поговорим, как собрать минимальный набор компонент, необходимый для работы в микросервисной архитектуре и достойный использования в боевой системе. В третьей части мы покажем, как расширять эту библиотеку, подстраиваясь под нужды вашей системы, а завершит цикл статей разбор различных сценариев, встречавшихся в жизни многих разработчиков с рекомендациями для каждого случая.

Шесть месяцев назад ребром встал вопрос о тексте для моего дипломного перевода. Результатом помощи коллективного разума стало решение переводить главу Scalable Web Architecture and Distributed Systems за авторством Kate Matsudaira. Нужно отметить, что это мой первый перевод такого объема и сложности. Текст, был мною относительно успешно переведен, хотя по качеству перевода я поставил бы себе 6-7 из 10. Дабы мои усилия не пропали втуне, публикую результат своих трудов.

По просьбам читателей Хабра, теперь полная версия в виде топика.

Масштабируемая веб-архитектура и распределенные системы

Кейт Матсудейра

Перевод: jedi-to-be.
Коррекция: Anastasiaf15, sunshine_lass, Amaliya, fireball, Goudron.

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

Если оглядеться вокруг, то может сложиться впечатление, что отрасль разработки ПО шагает такими громадными шагами, что угнаться за ней нет никакой возможности. И если рассматривать всю отрасль в целом, то действительно это так и есть. Как-то сразу вспоминается старина Брукс со своим «Мифическим человеко-месяцем», когда он в заключении к своей книге пишет о том, как изменилась индустрия ПО в середине 90-х по сравнению с 50-ми годами. В те далекие годы (да, 90-е тоже уже далеки, так что уж говорить за эпоху зарождения индустрии сорока годами ранее) можно было прочитать все журналы (!), компьютерной тематики, которые выходили в свет. Сейчас же ежемесячно появляется десятки книг только по одной из популярных технологий, а количество статей просто не поддается счету.

Мотивация

Для desktop-мира wcf остаётся самым распространенным способом организации клиент-серверного взаимодействия в .net как для локальных, так и для глобальных сетей. Он гибок в настройке, прост в использовании и прозрачен.

По крайней мере, так должно быть. На практике добавление нового сервиса — это рутина. Нужно не забыть прописать конфигурацию на сервере, сделать то же самое на клиенте, нужно написать или сгенерировать proxy-класс. Поддерживать конфиги неудобно. Если сервис изменился, то нужно вносить изменения в proxy-класс. А ещё не забыть про регистрации в IoC-контейнере. И добавление новых хостов для новых сервисов. И еще хочется простой асинхронности. По отдельности всё просто, но даже для статьи я дописывал этот список уже трижды, и не уверен, что не упустил чего-нибудь.

Время автоматизировать. Простейший сценарий от создания решения до вызова wcf-сервиса выглядит так:

1. Install-Package Rikrop.Core.Wcf.Unity
2. Пишем ServiceContract и их реализации
3. На сервере и клиенте добавляем одну строку регистрации в IoC (конфиги править не надо)
4. Поднимаем хосты с двух строк
   

   var assembly = Assembly.GetExecutingAssembly();
   _serviceHostManager.StartServices(assembly);
   

5. На клиенте резолвим IServiceExecutor<TService>. Эта обёртка служит для вызова методов сервиса и скрывает работу с каналом.
6. Можно пользоваться

   var articles = await _myServiceExecutor.Execute(service => service.GetArticles());
   

Меня все спрашивают — «Зачем это нужно?». На что, я гордо отвечаю — «Я в 1С использую для доступа к торговому оборудованию, к Вэб-сервисам по ws-протоколам, готовым компонентам. 1С, Linux, Excel, Word, OpenXML,ADO и Net Core. Кроме того, сделаю передачу JS объектов на сторону .Net с использованием через DynamicObject.

Можно сделать определенную конфигурацию CEF для всех платформ и можно делать кросспалатформенные декстопные приложения. Как аналог Electron. .Net Core развивается и можно достаточно легко перевести приложения под WPF и UWP на Angular 2» сделав описание классов и использовать IntelliSense при кодировании на TypeScript.

Но я прекрасно понимаю, что это всего лишь высокопарные слова, и мало кому это нужно. Но мне чертовски интересно, особенно после программирования на 1С.