Недавно на профильном ресурсе один программист задал вопрос: «Что использовать в сервере ММО для работы с потоками?». Программист склонялся к Intel TBB, но даже не к базовым примитивам, а к кастомному планированию задач (task scheduling). Ну нравится TBB — ну и ладно. А немного позже я увидел исходники сервера ММО другого программиста, который недавно начал переписываться его с нуля для улучшения архитектуры. И там было очень много велосипедов, которые писались самим программистом вместо того что бы использовать сторонние компоненты такие как boost (к примеру класы обертки над pthread-ом, и это в 2010 году, когда boost.thread уже почти в стандарте). Была там реализована и поддержка пула потоков с планировщиком задач. Тема эта мне очень интересна и я начал копать информацию о готовых решениях планировки задач (как в TBB) и нашел boost.task, про что и решил написать.

Про MongoDb было рассказано не так много, но относительно полно, например здесь. Хочу поделиться еще с одним практическим использованием этой БД — это построение цепочек друзей. Построение цепочек и концепцию кругов было использовано в Мойм Круге. Вот пример: Я — Иван Петров — Петр-Иванов — Киририлл Лавров — Вася Пупкин.

MongoDb было выбрано как высокопроизводительное хранилище данных, позволяющее быстро извлекать массивы структур данных. Традиционные key/value DB для этого не подходят, почему — поймете по ходу изложения статьи.

В данной статье рассмотрен опыт использования noSQL DB при построение «цепочек друзей» в небольшой соц-сети 300 тыс пользователей.

Условия

Мы используем MySQL для хранения любых данных FriendFeed. Наша база данных растёт вместе с числом пользователей. Сейчас у нас более 250 миллионов записей, это записи пользователей (post'ы), комментарии, оценки («likes»)

По мере того как росла база данных, мы время от времени имели дело с проблемами масштабируемости. Мы решали проблемы стандартными путями: slave-сервера, используемые только для чтения, memcache для увеличения пропускной способности чтения и секционирование для увеличения пропускной способности записи. Однако, по мере роста, использованные методы масштабируемости привели к затруднению добавлению новой функциональности.

В частности, изменение схемы базы данных или добавление индексов к существующим 10-20 миллионов записей приводили к полной блокировке сервера на несколько часов. Удаление старых индексов требовало времени, а не удаление ударяло по производительности, так как база данных продолжала использовать их на каждом INSERT. Существуют сложные процедуры с помощью которых можно обойти эти проблемы (например создание нового индекса на slave-сервере, и последующий обмен местами master'a и slave), однако эти процедуры настолько тяжелые и опасные, что они окончательно лишили нас желания добавлять что-то новое, требующее изменение схемы или индекса. А так как наши базы сильно распределены, реляционные вещи MySQL как например JOIN никогда не работали для нас. Тогда мы решили поискать решение проблем, лежащее вне реляционных баз данных.

Существует множество проектов, призванных решить проблему хранения данных с гибкой схемой и построением индексов на лету (например CouchDB). Однако, по-видимому ни один из них не используется крупными сайтами. В тестах о которых мы читали и прогоняли сами, ни один из проектов не показал себя стабильным, достаточно зрелым для наших целей (см. this somewhat outdated article on CouchDB, например). А все это время MySQL работал. Он не портил данные. Репликация работала. Мы уже в достаточной мере понимали все его узкие места. Нам нравился MySQL именно как хранилище, вне реляционных шаблонов.

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

Качество программного продукта не в последнюю очередь зависит от актуальной документации и тщательного тестирования. Хотелось бы осветить вопрос разработки и тестирования ПО вообще и с использованием среды FitNesse в частности.

Управляемая память в .Net поделена на стек и несколько хипов. Самые важные из хипов – это обычная (эфемерная) куча и LOH. Эфемерная куча – это то место, где живут все обычные объекты. LOH – это то место где живут большие (больше 85000 байт) объекты.

LOH обладает некоторыми особенностями:

• Объекты в LOH никогда не перемещаются
• LOH только растет и никогда не уменьшается (т.е. если объект собран сборщиком мусора, размер LOH все равно остается неизменным)
• Хип LOH освобождается только тогда, когда LOH полностью пуст

Из этих двух особенностей LOH происходят два важных следствия, про которые часто забывают:

• Память в LOH может оказаться фрагментированной. Т.е. происходит то, с чем так боролись в unmanaged мире: в какой-то момент у вас может быть 10Mb свободной памяти, но вы не сможете выделить память под объект размером 1Mb
• Если вы однажды выделили память под большой объект, а потом используете только маленькие, то вы фактически лишаете себя большого куска памяти. При чем, если у вас в LOH был список или хэш-таблица размером N, а вы добавили в него один элемент, то список реаллоцируется и растет в два раза, сответственно размер LOH составит как минимум 3*N (N – исходные данные, 2N – копия данных и резерв под новый размер). Следующий рост потребует в LOH непрерывный кусок памяти размером в 4*N, а так как такого куска в LOH у нас нет (есть только N), его придется позаимствовать из адресного пространства процесса. В итоге размер LOH вырастет до 7*N, и так далее.

Если вспомнить, что LOH аллоцируется кусками по 16Mb, то все происходящее покажется еще более разрушительными. С первым следствием можно бороться аккуратно переиспользуя объекты. Со вторым — не используя большие объекты. Получается как-то не очень, особенно если с большими коллекциями работать все-таки хочется. Посмотрим, что как можно решить эту проблему.

Добрый день!

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

Начнем знакомство непосредственно с использованием технологии OpenMP и рассмотрим в этой заметке некоторые базовые конструкции.

.NET 4.0 уже не за горами и принесет кучу всего нового, нужного и не очень, крутого и суперкрутого. Однако и в старом добром .NET 3.5 есть много разных интересных фич, которые не используются в повседенвной работе, но иногда здорово облегчают жизнь разработчикам. Одна из таких замечательных штук — это Expressions.

Мы регулярно пишем статьи посвященные разработке и тестированию 64-битных программ на языке Си/Си++. Каждая из статей представляет взгляд на задачу разработки 64-битных программ с разных точек зрения. Но существенная часть информации в них повторяется, так как необходимо знакомить читателя с проблематикой и вводить различные определения. Это, к сожалению, делает чтение подборки статей скучным занятием и соответственно не позволяет всесторонне изучить вопросы разработки 64-битных приложений.

Мы решили объединить все наши знания в единый труд, в котором будут рассмотрены сразу все вопросы, касающиеся 64-битного программирования. Для оформления в виде статьи материала оказалась слишком много и мы решили представить его в виде курса уроков.

Кратко опишу курс "Уроки разработки 64-битных приложений на языке Си/Си++" и приведу его содержание.

Исходники проекта написанного с помощью TDD. Visual Studio 2008/C#
Для написания тестов использована библиотека xUnit, для создания mock-объектов – Moq.

---

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

Мне задают много вопросов про TDD. Из этих вопрсов я выбрал ключевые и написал на них ответы. Сами вопросы вы можете найти в тексте, они выделены курсивом.

Недавно я попал на новый проект, с задачей создать небольшое приложение с нуля. Разговариваю с тестером:
— А как тебе новые версии поставлять?
— Можешь как все остальные на проекте, через SVN.
— То-есть ты сама билдить будешь?
— Да нет… Бинарники оттуда беру.

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

Сказка

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

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

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

Наверное, не многие знают о существовании такого типа баз данных, как базы данных на основе графов (graph db). Ранее в NOSQL среде была распространена всего одна система такого плана — Neo4j. Сегодня же к нам прибыло еще 2 — Infogrid и HyperGraphDB. О последнем и пойдет речь.

Как описывают сами создатели свою систему:

«HyperGraphDB — это расширяемая, портативная, распределенная, встраиваемая система общего назначения со свободным (open-source) механизмом хранения данных. Эта система разработана специально для проектов использующих возможности искусственного интеллекта и семантического вэба и может использоваться как встраиваемая, объектно-ориентированная база данных для проектов любого масштаба.»

Просто список примеров реализации паттернов на C#, более-менее хорошо сформатированных.
Делал для себя, но может быть кому-нибудь пригодится.



depositfiles.com/files/gl3ux6p07
2u.ifolder.ru/16126054
fileland.ru/file_id-248997
foldo.ru/38053i807d/Pattierny_kratko.doc.html

Многие уже наслышаны о революции в расширении HTTP протокола — внедрении технологии WebSocket разработчиками Google Chromium. В данной статье речь пойдет о том, как приручить данного зверя — установке и настройке WebSocket сервера на асинхронном фреймворке phpDaemon.

Не так давно в рамках разработки крупного ASP.NET проекта возникла следующая подзадача: реализовать визуальное отображение табличных данных, обновляющихся в режиме real-time. Схема обновления довольно проста, а именно: на сервер посредством QueryString присылаются данные, которые должны как можно быстрее заменить собой устаревшие данные на странице, причем без необходимости страницу эту рефрешить. Первым решением, которое сразу же пришло мне в голову, было использовать ставшую уже общепринятой технику AJAX-запросов по таймеру, скажем, каждые 5 секунд. Однако сразу же выявились очевидные недостатки применения такого подхода: во-первых, довольно внушительное число потенциальных клиентов, дергающих сервер каждые 5 секунд с созданием каждый раз нового соединения, а во-вторых, это все-таки довольно грубая эмуляция real-time'а, ведь данные на сервер гипотетически могут приходить даже по несоколько раз в секунду (а могут не приходить и по несколько минут, и это уже больше относится к «во-первых»).

Идея решения пришла довольно неожиданно от коллеги по работе, поделившегося линком на статью на Хабре, описывающую реализацию технологии Comet на Perl в целях создания веб-чата. "Comet — это то что нужно!", — подумали мы, и я начал разбираться, как же эту штуку можно прикрутить к ASP.NET. О чем, собственно, и пойдет речь под катом.

Для вывода в лог (да и не только для этого, но это то, с чем я сам столкнулся) нужно конвертировать значение переменной в строку.

В C++ это обычно делается выводом в поток (как вариант — использование boost: lexical_cast<> — что в нашем случае практически одно и тоже).

Для встроенных типов это не проблема, а вот как быть, если нужно вывести скажем std: vector? Увы, но у std: vector нет оператора вывода в поток.

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

В предыдущей статье мы выяснили, что такое Google AppEngine, что с ним можно делать, и создали самое простое и примитивное приложение для GAE — helloworld с минимальной поддержкой аутентификации пользователей. Попробуем расширить это приложение, рассмотрев, попутно, возможности Google AppEngine.

Структура и архитектура

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

Git это еще одна системы для управления исходным кодом, аналогичная subversion, cvs и другим. Почему аналогичная, а не «новая», «быстрая» и тп? SCM (source code management) прежде всего инструмент, который позволяет выполнять операции необходимые для одного разработчика и команды в целом. При каждый инструмент имеет свои достоинства и недостатки.

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