RAII – одна из наиболее важных и полезных идиом в C++. RAII освобождает программиста от ручного управления ресурсами, без неё крайне затруднено написание безопасного с точки зрения исключений кода. Возможно, самое популярное использование RAII – это управление динамически выделяемой памятью с помощью умных указателей, но она также может с успехом применяться и к другим ресурсам, особенно в мире низкоуровневых библиотек. Примеры включают в себя дескрипторы Windows API, файловые дескрипторы POSIX, примитивы OpenGL и тому подобное.

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

Предыстория

Зовут меня Эдуард Черненко, я администратор Абсурдопедии.
Некогда мы вляпались в чёрный список в первый месяц его работы, о чём был предыдущий хабратопик: «Чёрные списки: как мы судились с Роспотребнадзором (часть 2)».
Как говорится, никогда такого не было, и вот опять.

Началось всё с того, что решил я в конце 2013 года погуглить по запросу вроде «Абсурдопедия суд». Гугл выдал вот что: rospravosudie.com/court-pyatigorskij-gorodskoj-sud-stavropolskij-kraj-s/act-428488026

[...] выявлены сайты, на которых размещены предложения о незаконной продаже оружия и информация о способах изготовления оружия и взрывных устройств в кустарных условиях [...] http://absurdopedia.net/wiki/Как_правильно: изготовить_дома_бомбу [...]

Введение

Данная статья предназначена к прочтению разработчикам и архитекторам распределенных систем на платформе .NET. В ней будет рассмотрен гибкий каркас для объектно-объектного преобразования (далее маппинга). Так же будут рассмотрены некоторые аспекты Domain-Driven Design’а.

О чем речь?

Речь в этой заметке пойдет о библиотеках для автоматического копирования полей одного объекта в поля другого (мэппинг объектов). О том, для чего это надо можно почитать, например, тут.

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

1) AutoMapper
2) BLToolkit
3) EmitMapper

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

Dapper.NET — это «мини-ORM», как ее называют сами разработчики, на которой работает движок StackExchange и сайт StackOverflow в частности.

Сегодня Sam Saffron (@samsaffron, один из разработчиков платформы) выложил ее в OpenSource на Google Code.

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

Примерно, 3 недели назад я прочёл на хабре в этом топике о Dapper — ORM от одного из ведущих разработчиков популярного сайта Stackoverflow. Имя этого супергероя Sam Saffron (далее просто Сэм). Кроме того, до появления этого топика об архитектуре Stackoverflow было известно, что в ней используется Linq-to-Sql. Это главная причина, почему я, как и другие разработчики, принялся изучать исходный код Dapper. Как оказалось его немного, а точнее всего один файл. Внимательно просмотрев его, я подумал – а можно ли его сделать ещё быстрее. Ускорять код Сэма было не просто, слишком качественно он был написан. Дальше я опишу мои микрооптимизации в виде советов другим разработчикам. Но для начала хочу предостеречь некоторых разработчиков. Описанная оптимизация ускорила Dapper на 5% и это существенно для такого проекта как Stackoverflow, но может быть не существенным для вашего проекта. Поэтому всегда рассматривайте вариант макрооптимизации (примеры в конце топика) по результатам профилирования и прибегайте к микрооптимизации только в особых случаях.

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

В процессе работы над проектом веб-портала, я исследовал возможности улучшить производительность, и наткнулся на небольшую статью про микро-ORM Dapper, который был написан авторами проекта StackOverflow.com. Изначально их проект был написан на Linq2Sql, а теперь все критичные к производительности места переписаны с использованием означенного решения.
Недостаток этого, а также других подобных решений, которые я успел посмотреть, в том, что они уж очень незначительно помогают облегчить процесс разработки, предоставляя по большому счету лишь материализацию, скрывая работу с непосредственно ADO.Net. SQL запросы же нужно писать руками.

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

Linq появился в 2007 году, тоже же появился первый IQueryable-провайдер — Linq2SQL, он работал только с MS SQL Server, довольно сильно тормозил и покрывал далеко не все сценарии. Прошло почти 7 лет, появилось несколько Linq-провайдеров, которые работают с разными СУБД, победили почти все «детские болезни» технологии и, уже пару лет как, Linq to Database (обобщенное название для популярных провайдеров) готов к промышленному применению.

Тем не менее далеко не все применяют Linq to Database и объясняют это не только тем, что проект старый и переписать на linq довольно сложно, но и приводят в качестве аргументов различные мифы. Эти мифы кочуют из одной компании в другую и часто распространяются через интернет.

В этом посте я собрал самые популярные мифы и опровержения к ним.

Миф #1

Все LINQ запросы должны начинаться с ключевого слова 'var'. По сути основная цель ключевого слова 'var' — начать LINQ запрос!

Ключевое слово var и LINQ — это самостоятельные концепции. Ключевое слово var позволяет компилятору вывести тип локальной переменной на основании начального присваивания(неявная типизация). К примеру, следующий код:

var s = "Hello"; 

точный эквивалент для:

string s = "Hello"; 

потому что компилятор выводит тип переменной s как string.

В этой статье я расскажу о различных приемах разработки SOAP веб-сервисов по технологии ASMX, а также об этой технологии в целом. Кроме SOAP, также будет рассмотрена реализация AJAX. Статья будет полезна как тем, кто уже знаком с ней, так и тем, кто только собирается создать свой первый веб-сервис.

Хорошо в плане поддержки JSON живётся программистам на Javascript — по какому-то невероятному стечению обстоятельств там JSON входит в спецификацию самого языка: есть JSON — есть объект. Удобно. Неплохо дело обстоит и в языках, где JSON не входит в сам язык, но поддерживается стандартной библиотекой (Python, Ruby): импортируешь модуль — и готово.

Жизнь программистов на С++ никогда не была особо простой — поддержки JSON у нас нет ни на уровне языка, ни в стандартной библиотеке. И не будет, возможно, никогда. «Тоже мне проблему нашел!» — скажут мне опытные коллеги — «Её там и не должно быть, С++ поставляется без „батареек“. Для решения этой задачи мы...» и вот здесь они разделятся на два лагеря:

1. «Мы используем большой фреймворк (boost, Qt, POCO, другой), который применяется во всех наших проектах и умеет 150 000 разных вещей, в том числе и JSON.»
2. «Мы придерживаемся подхода в котором для каждой задачи применяется своя легковесная библиотека. В частности, для JSON мы уже 150 000 лет назад выбрали отличную библиотеку %JSON_LIB%, которая прекрасно работает.»

Да, всё так и есть. Вот только…





Давайте немного помечтаем.

А что, если бы JSON вошел в стандартную библиотеку нового стандарта С++? Что, если бы он был написан в терминах С++11\14 и без требований обратной совместимости со старыми стандартами языка? Что, если бы синтаксис этого модуля попытались бы сделать максимально приближенным к родному для JSON использованию «а-ля Javascript», но в том же время сохранить дух С++ (эффективность, минимальное потребление памяти, совместимость с STL)? Что, если бы его можно было включить в проект одним инклюдом и не беспокоиться о его сборке и линковке? Как бы это всё выглядело и работало?

И у нас есть ответ на этот вопрос! Давайте посмотрим на JSON-библиотеку для С++ написанную в соответствии со всеми этими принципами, ну и вообще написанной людьми для людей, а не чужими для хищников, как это обычно бывает.

Что такое интернационализация?

Интернационализация (internationalization, а для краткости — i18n, то бишь i, ещё 18 букв и n; по-русски это получится и17я) – такой способ создания приложений, при котором их можно легко адаптировать для разных аудиторий, говорящих на разных языках. Очень легко ошибиться, предполагая, что все ваши пользователи происходят из одной местности и пользуются одним языком – особенно, если вы даже не задумываетесь о том, что предполагаете именно это.

function formatDate(d)
{
  // Все же пишут дату, как месяц/день/год. Правда ведь?
  var month = d.getMonth() + 1;
  var date = d.getDate();
  var year = d.getFullYear();
  return month + "/" + date + "/" + year;
}
 
function formatMoney(amount)
{
  // Все деньги – это доллары, с двумя знаками после запятой. Ведь так?
  return "$" + amount.toFixed(2);
}
 
function sortNames(names)
{
  function sortAlphabetically(a, b)
  {
    var left = a.toLowerCase(), right = b.toLowerCase();
    if (left > right)
      return 1;
    if (left === right)
      return 0;
    return -1;
  }
 
  // Имена всегда сортируются по алфавиту, не так ли?
  names.sort(sortAlphabetically);
}

Продолжаем цикл пятничных статей "X глазами C++ программиста" (1, $$). В этот раз под катом вас ждут впечатления заядлого С++ программиста от мира администрирования. Боль, страдания, радости и прочие эмоции как всегда вынесены под спойлеры.

Надеюсь будет интересно профессиональным администраторам посмотреть на потуги С++ника, ну а С++ разработчикам узнать для себя что-то новое.

Хакер — человек, который наступает на грабли, которые спрятаны в сарай и закрыты на замок

Mongoose — самый популярный модуль для работы с mongodb на javascript. Примеры на сайте позволяют достаточно быстро и успешно начать его использовать, однако mongoose имеет ряд неожиданных особенностей, которые могут заставить программиста начать выдирать волосы на голове. Именно об этих особенностях я и собираюсь рассказать.

Наш стартап Olery был основан почти 5 лет назад. Мы начали с единственного продукта, Olery Reputation, который был создан агентством, занимавшимся разработкой на Ruby. Всё это выросло в набор различных продуктов. Сегодня у нас есть ещё Olery Feedback, API для Hotel Review Data, виджеты для вставки на сайты и многое другое.

Всего у нас работает 25 приложений (все на Ruby) – некоторые из них в вебе (Rails или Sinatra), но в основном это фоновые приложения для обработки данных.

Хотя нам есть, чем гордиться, есть у нас одна проблема, которая всё время висела где-то в фоне – база данных. Изначально мы использовали MySQL для важных данных (пользователи, контракты, и т.д.) и MongoDB для хранения обзоров и других данных, которые легко можно было бы восстановить в случае утери. Сначала всё работало неплохо, но по мере роста мы начали испытывать проблемы, в особенности с MongoDB. Некоторые из них возникали в сфере взаимодействия БД с приложениями, некоторые – непосредственно у самой БД.

К примеру, в какой-то момент нам надо было удалить миллион документов из MongoDB, а позже вставить. В результате работа базы застопорилась на несколько часов. Потом нам пришлось запускать repairDatabase. И сама починка тоже заняла несколько часов.

Так уж случилось, что последнее время приходилось заниматься оптимизацией и масштабированием различных систем. Одной из задач было масштабирование PostgreSQL. Как обычно происходит оптимизация БД? Наверное, в первую очередь смотрят на то, как правильно выбрать оптимальные настройки для работы и какие индексы можно создать. Если обойтись малой кровью не вышло, переходят к наращиванию мощностей сервера, выносу файлов журнала на отдельный диск, балансировке нагрузки, разбиению таблиц на партиции и к всякого рода рефакторингу и перепроектированию модели. И вот уже все идеально настроено, но наступает момент, когда всех этих телодвижения оказывается недостаточно. Что делать дальше? Горизонтальное масштабирование и шардинг данных.

В статье данные сведения по заголовкам кэширования (ЗК) для HTTP и соответствующее поведение сетей доставки контента (CDN). Если вам хочется разобраться, каким образом заголовки кэширования вписываются в современный веб, или вам просто интересно, о чём говорят ваши коллеги – эта статья для вас.

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

Что могут ЗК сделать для вас?

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

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

Никогда не думали, а что если паттерны ООП спроецировать на работу программистов?

Singleton-разработчик
Разработчик с bus-factor=1. Как правило, один из «старожилов» проекта, который приложил руку ко многим компонентам и только он знает как эти части работают вместе. Практически «невыпиливаемый» из проекта, либо без него все начинает «работать как-то не так». По любому вопросу «как оно работает» всегда отвечает «да мне проще самому запилить» и запиливает.

Если вы когда-нибудь сталкивались с задачей ресайза картинок в браузере, то вы наверное знаете, что это очень просто. В любом современном браузере есть такой элемент, как холст (<canvas>). На него можно нанести изображение нужных размеров. Пять строчек кода и картинка готова:

function resize(img, w, h) {
  var canvas = document.createElement('canvas');
  canvas.width = w;
  canvas.height = h;
  canvas.getContext('2d').drawImage(img, 0, 0, w, h);
  return canvas;
}

Из холста картинку можно сохранить в JPEG и, например, отправить на сервер. Можно было на этом закончить статью, но сперва давайте взглянем на результат. Если вы поставите рядом такой холст и обычный элемент <img>, в который загружена та же картинка (исходник, 4 Мб), то вы увидите разницу.