Всем привет. Как-то на просторах Интернета мне попался интересный американский проект. Суть проекта в том, что можно выращивать различные агрокультуры, используя не почву, а, так сказать, симбиоз рыб с растениями. Получается замкнутый цикл. Вы кормите и выращиваете рыб, их продукты жизнедеятельности, растворённые в воде, являются питательной средой для растений. А эти растения, получая питательные вещества для роста из воды, очищают её. Весь процесс повторяется по кругу. Данный метод называется «аквапоника».

Когда .NET разработчик слышит слова «В проект нужно добавить workflow», то первым приходит в голову идея взять Windows Workflow Foundation.

В 2010 году мы выбрали WF в качестве движка документооборота.

Аргументы просты:

• Бесплатно;
• Встроено в Visual Studio;
• В интернете много информации об использовании WF.

За полтора года (с августа 2010 по февраль 2012) использования WF мы столкнулись с массой разнообразных проблем при реализации требований клиента. В конечном итоге мы были вынуждены отказаться от Windows Workflow Foundation и сделать свою реализацию State Machine.

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

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

Бельгийские разработчики представили новый алгоритм, который превосходит все существующие аналоги по вычислительной скорости. Вследствие этого его можно применять на базах беспрецедентного размера: анализ типичной сети из 2 млн нодов занимает 2 минуты. Он получил название Лувенский метод (Louvain Method), поскольку создан в то время, когда все разработчики трудились в Лувене (Бельгия).

Пожалуй, начну с того, что если перегружаться 15 раз в год, то любой «тюнинг» процесса загрузки отнимает больше времени, чем будет выиграно на перезагрузках за все время жизни системы. Однако, спортивный интерес берет свое, тем более, что люди интересуется процессом оптимизации быстродействия. А загрузка оказалась самым очевидным кандидатом в примеры того, как на мой взгляд должен выглядеть этот самый процесс. Сразу скажу, что грузиться будем с 5400 rpm винта, грузиться будем в «рабочую» систему: помимо недобитой вендорской крапвари там стоит еще куча всякого типа вижуал студии, антивируса, скайпа, стима, гуглапдейтера и пр…

Про то, почему отключение pagefile-а скорее вредно, чем полезно — как нибудь в другой раз, а пока…

В продолжение статьи TijAY.

Недавно возникла интересная история — на компьютере потерпевшего с завидной регулярностью светился BSOD. К его чести — машина в перезагрузку уходила быстрей, чем удавалось прочитать STOP-код. Выход тут один: анализировать дампы памяти.
Учитывая, что дампов этих накопилось очень большое количество, открывать каждый дебаггером показалось мне слишком утомительным.

Предисловие

Недавно на работе задали задачу — есть клиент с GPS устройством. Ходит, он значит по городу и записывает на это устройство каждую секунду координату своего местонахождения. Потом заходит на наш сайт и отправляет файл с записями маршрута. И в ответ получает изображение карты и поверх нарисованный маршрут по которому он двигался. Все вроде бы ничего, но есть одна проблемка — клиент может записывать хоть целый день и прислать громадный файл, а отрисовка маршрута занимает очень много времени. А он ведь мог идти по прямой линии и тогда смысл отрисовывать все точки отпадает(ценных только две крайних). Тем более рисуется она на JavaScript на клиентской стороне и если клиентская сторона это мобильное устройство вполне вероятно что маршрут он не увидит((
И потому мне надо было сделать небольшую оптимизацию — оптимально упростить ломанную линию. Для этой задачи существует метод Дугласа-Пекера, но на русском описания этого метода я не нашёл, поэтому я решил заполнить этот пробел рунета.

Вариантность всегда была для меня слишком сложной темой, чтобы разобраться в ней. Недавно я делал доклад о новых особенностях C# 4.0 и вариантность была одной из охваченных мной тем. Я хотел бы начать с распространенного сценария, который мне всегда было трудно понять. Возьмем вот такой фрагмент кода:

1. IList<object> stuff = new List<string>();

* This source code was highlighted with Source Code Highlighter.

Это не будет компилироваться ни в одной из существующих версий .NET Framework. Я всегда пытался понять, почему бы этому не работать. Тип System.String, безусловно, удовлетворяет все требования System.Object. Так почему же это не работает? Обобщение List – это ссылочный тип, что означает что каждый раз когда кто-то сошлется на объект этого типа в коде, он получит указатель на некоторое место в куче. И неважно сколько раз вы используете List, вы всегда получаете ту же самую ссылку т.к. это ссылочный тип. Так вот, давайте разовьем наш предыдущий пример:

Попробую внести свою лепту в освоение относительно неосвоенного фреймворка ASP.NET MVC и предлагаю вашему вниманию перевод отрывка из книги "Pro ASP.NET MVC Framework" под названием «The Request Processing Pipeline».

***

Давайте рассмотрим, что происходит в режиме runtime, когда ASP.NET MVC обрабатывает входящий запрос.

Конвейер обработки запросов в ASP.NET MVC сравним с жизненным циклом страницы в ASP.NET WebForms в том, что он отображает анатомию системы. Понимание этого процесса необходимо для выполнения каких-либо нестандартных задач. В отличие от традиционного жизненного цикла страницы в ASP.NET, конвейер обработки запросов в MVC очень гибок – можно изменить любую его часть так, как вам хочется, и даже перераспределить или заменить некоторые компоненты. Хотя обычно не приходится расширять или изменять конвейер, можно сделать это в любой момент, потому как расширяемость лежит в основе ASP.NET MVC.

Использование Google static maps

В статье рассмотрены основные возможности использования статических карт Google на основе собственного опыта автора.

Google предоставляет два варианта использования своих картографических сервисов.

• Google maps, базирующийся на JavaScript API, предоставляющий разнообразные возможности для отображения различной географической информации.
  Имеется хорошо продуманная и структурированная библиотека классов, с документацией к которой можно ознакомится по следующим ссылкам:
  English, Русский и поиграться в песочнице
  

Исходя из параметров запроса, загрузить данные из источника — рутина, с которой сталкивается разработчик веб-страниц. В статье рассмотрен подход, позволяющий сократить время необходимое для связывания параметров страницы с источником данных. Описана реализация этого подхода для платформы .NET.

Функция для конвертирования размеров файла, из байт в мегабайты, гигабайты и т.п.

function file_size($size)
{
$filesizename = array(" Bytes", " KB", " MB", " GB", " TB", " PB", " EB", " ZB", " YB");
return $size ? round($size/pow(1024, ($i = floor(log($size, 1024)))), 2) . $filesizename[$i] : ‘0 Bytes’;
}


Всем известно, что «большая часть времени уходит на загрузку компонентов страницы: картинок, таблиц стилей, скриптов, flash… Уменьшение количества этих компонентов уменьшает количество запросов к серверу, необходимых до того, как клиентское приложение может отрендерить страницу.» Я всегда сжимал и объединял *.js и *.css файлы вручную, но последнее время меня это стало немного доставать, и я решил упростить этот процесс. Для этого я перерыл кучу всего на гугле и тематических форумах в поисках нужной мне информации, а потом просто собрал всё вместе.
Для сжатия javascript'a я использовал jscompress, немного изменённый для моих нужд.
Вот что получилось:

Я работаю с удивительным человеком. Каждый раз, когда я смотрю в bugzill'у или проверяю почту, я им поражаюсь. Иногда мне кажется, что он мог бы стать неплохим писателем. Во всяком случае графоман из него отличный.

Этот разработчик принимает документирование очень близко к сердцу.

Каталог:
Один
Два
Три

μTorrent

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

Каталог:
Один
Два
Три

Оказывается длинные опусы нужно разбивать. А я то думал «многосерийные» топики публикуют исключительно для зарабатывания рейтинга :-)

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

Каталог:
Один
Два
Три

Менеджер памяти (и связанные с ним вопросы контроллера кеша, менеджера ввода/вывода и пр) — одна из вещей, в которой (наряду с медициной и политикой) «разбираются все». Но даже люди «изучившие винду досконально» нет-нет, да и начинают писать чепуху вроде (не говоря уже о другой чепухе, написанной там же):

Грамотная работа с памятью!!! За все время использования у меня своп файл не увеличился ни на Килобайт. По этому Фаерфокс с 10-20 окнами сворачивается / разворачивается в/из трея как пуля. Такого эффекта я на винде добивался с отключенным свопом и с переносом tmp файлов на RAM диск.

Или к примеру μTorrent — у меня нет никаких оснований сомневаться в компетентности его авторов, но вот про работу памяти в Windows они со всей очевидностью знают мало. Не забываем и товарищей, производящих софт для слежения за производительностью и не имеющих ни малейшего понятия об управлении памятью в Windows (и поднявших по этому поводу истерику на пол интернета, на Ars-е даже был разбор полетов). Но самое потрясающее, что я видел всвязи с управлением памятью — это совет переместить pagefile на RAM-диск:

Из моих трех гигабайт под RAM disk был выделен один (на тот момент, когда на лаптопе еще была установлена XP), на котором я создал своп на 768МБ ...

Цель данной статьи — не полное описание работы менеджера памяти (не хватит ни места ни опыта), а попытка пролить хоть немного света на темное царство мифов и суеверий, окружающих вопросы управления памятью в Windows.

История появления на свет центрального домашнего контроллера довольно запутанна. Мне кажется, если на секунду отвлечься и представить его в виде зимнего леса (вид сверху), то можно будет увидеть беспорядочные тропинки, плохо замаскированные ямы и, возможно, бродящего где-то в глуши И. Сусанина.

Функционал наращивался постепенно: сначала подключил беспроводные розетки, потом замахнулся на выключатели света. Аппетиты росли — датчики протечки, задымления, дверей, метеодатчики, радиореле и управление AV-техникой. Мастерство росло не так быстро. Поэтому получилось то, что получилось: вещь, бесконечно далекая от гайдлайнов по программированию и устройству электронных схем, но вполне работоспособная.

И знаете что? Меня это устраивает.

Привет Хабр! Примерно год назад я представил вашему вниманию первую версию open-source библиотеки FileAPI, предназначенную для работы с файлами на клиенте и последующей загрузки на сервер.

За это время был пройден долгий путь. Библиотека заработала 670+ звезд и 90+ форков. С помощью github-сообщества удалось исправить множество «детских» проблем и внести ряд улучшений. Было закрыто более 100 тасков, и благодаря Илье Лебедеву сделана загрузка файлов по частям. Сегодня я с гордостью хочу представить вам FileAPI 2.0.

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

Всем добрый день!

Бывало ли у вас такое, что вы долго думали над какой-то рабочей (или личной ситуацией), а потом вдруг раз! и все как будто раскладывалось по полочкам? У нас такое бывало неоднократно.

Вместо пролога. Более того, это в некотором смысле наша профессия — раскладывать по полочкам сложные ситуации. Потому что последние 7 лет мы с коллегами занимаемся обучением IT-специалистов и руководителей навыкам управления людьми и тому, что называется soft skills.

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

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

Все инструменты, о которых мы будем писать, очень простые. Либо это матрицы 2 на 2, либо 4 вопроса, либо что-то в таком же духе. Поскольку мы много работаем с менеджерами, то обнаружили, что матрицы 3 на 3 некоторым менеджерам уже сложновато воспринимать (хей, мы сами были менеджерами, знаем о чем говорим :)), а 2 на 2 — в самый раз, отлично заходят.

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

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

Итак, довольно лишних слов, давайте перейдем к первому инструменту (всего мы планируем разобрать около 15 разных полезных концептов):