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

Основы программирования

• codebetter.com/karlseguin/2008/06/25/foundations-of-programming-ebook
• pine.fm/LearnToProgram
• netlib.bell-labs.com/cm/cs/pearls
• www.faqs.org/docs/artu
• savannah.nongnu.org/projects/pgubook

Странно, но статей о извлечение знаний (data mining) и кластеризации (как одном из основных инструментом, которие используются для извлечения знаний) на Хабре совсем немного. А если говорить говорить о конкретных алгоритмах, то рассматривались только hard/soft k-means.

В статье ниже описывается теория и реализация (Python + matplotlib) не очень известного, но крайне интересного иерархического метода который можно назвать алгоритмом а-квазиэквивалентности.

Большинство программистов, которых нелегкая судьба свела с платформной.Net знают о существовании значимых типов (value types) и ссылочных типов (reference types). И довольно многие из них прекрасно знают, что помимо названия, эти типы имеют и другие различия, такие как расположение объектов оных типов в памяти, а также в семантике.

Что касается первого различия (о котором стоит упомянуть как минимум ради полноты изложения), то оно заключается в том, что экземпляры ссылочных типов всегда располагаются в управляемой куче, в то время как экземпляры значимых типов по умолчанию располагаются в стеке, но могут мигрировать в управляемую кучу вследствие упаковки, будучи членами ссылочных типов, а также при использовании их в хитрых экзотических конструкциях языка C#, типа замыканий (*).

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

Программное обеспечение проникает во все щели человеческого общества. Мы узнаем погоду через интернет, а не через обычный градусник за окном. Мы едем по новому адресу с навигатором, а не ищем квадрат G7 на странице 59. Мы включаем RunKeeper, когда катаемся на велосипеде, чтобы узнать среднюю скорость и похвастаться в твиттере. Мы используем софт каждый день. Наверное, бОльшую часть жизни мы уже проводим в обнимку с любимыми гаджетами и программным обеспечением, а не с любимым человеком.

Проблема в том, что никто не знает, как на самом деле писать классный софт быстро и правильно. Waterfall благополучно скончался на рубеже веков, а новые методы разработки (agile) пока не могут решить фундаментальные проблемы.

Важным этапом научного исследования является выбор темы и оценка степени разработанности проблемы. В современных условиях лавинообразного роста информации проблема выбора тема усложняется еще больше: ученый оказывается просто не в состоянии отслеживать все публикации в собственной области (не говоря уже о смежных областях). Кроме того, на начальном этапе исследования достаточно сложно (кто писал кандидатскую диссертацию, тот знает) отслеживать процесс изучения собственной области на современном этапе (т. е., получать актуальную информацию о том, кто, где и чем занимается, какие публикации выходят, какие диссертации защищаются и т. п.). В настоящее время данная задача облегчается при помощи научных социальных сетей, позволяющих ученым отслеживать (а в некоторых случаях — и скачивать) последние публикации по собственной, устанавливать контакт друг с другом, а также предоставляющих некоторые дополнительные возможности. Рассмотрим некоторые популярные социальные сети для ученых более подробно. Данный обзор не претендует на исчерпывающий характер; при выборе социальных сетей я руководствовался следующими критериями: 1) интернациональность (именно поэтому в обзор не попали сервисы, ориентированные на ученых какой-то одной конкретной страны) и 2) междисциплинарность (в первую очередь меня интересовали социальные сети, которые могут использоваться учеными самой разной специализации; именно поэтому обзор не затрагивает сервисов, ориентированных на представителей какой-то одной конкретной дисциплины). Буду очень рад, если с помощью читателей удастся расширить и дополнить этот список.

Оригинал опубликовал Лео Бабаута на сайте Zen Habits. Я его вольно перевел и немножечко адаптировал. Сразу оговорюсь, я не претендую на точность перевода. Моей задачей было перевести не точно, а понятно. Приятного чтения и применения!

«Это про привычки и делание, а не про систему и инструменты»

Чтобы закрепить основы продуктивности и организованности, сохраняя всё настолько простым, насколько возможно, я разработал свою собственную систему продуктивности: Zen To Done (ZTD).

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

С динамическими типами данных сложилась ситуация, схожая с АОП. А именно – полезных примеров применения этой техники можно пересчитать по пальцам, и они достойны коллекционирования (одна из коллекций по АОП собрана mezastel здесь). Сегодня, я надеюсь, мы добавим ещё пару таких примеров.

Предлагаю вашему вниманию введение в использование Protocol Buffers на платформе .Net в формате дискуссии. Я расскажу и покажу что это такое и зачем оно нужно .Net разработчику. Топик требует от читателя начального владения языком C# и системой контроля версий SVN. Так как объем материала превышает среднестатистический объем топиков на хабре, которые не вгоняют хаброюзеров в тоску и не заставляют их скроллить до комментариев, было принято решение разбить его на две части. В первой части мы познакомимся с основами и даже напишем (не)много кода!

Я уже однажды писал о том, что, несмотря на мою любовь к статической типизации, в некоторых сценариях преимущества от той свободы, которую дает динамическая типизация, может превосходить связанные с ней недостатки. В прошлый раз шла речь о Dynamic LINQ, а в этот раз речь пойдет об использовании новой возможности C# 4.0 под названием dynamic, для работы с такими исходно слаботипизированными данными, как XML.

ПРИМЕЧАНИЕ
Исходный код библиотеки DynamicXml, рассматриваемой в данной статье, доступен на github

Введение

Начиная с версии 4.0, в языке C# появилась поддержка динамического программирования, благодаря новому статическому типу под названием dynamic. По сути, применение этого ключевого слова говорит компилятору сгенерировать весь необходимый код, чтобы процесс привязки (binding) и диспетчеризации вызовов (dispatch operations) производился во время выполнения, вместо определения всех этих характеристик во время компиляции. При этом компилятор генерирует весь необходимый код с помощью библиотеки DLR – Dynamic Language Runtime (*), которая была изначально создана при проектировании языка программирования Iron Python и впоследствии вошла в состав .Net Framework 4.0, как основа для реализации динамических языков программирования, а также для взаимодействия между ними.

Университет Сан-Франциско создал с использованием HTML5 коллекцию визуализаций различных алгоритмов и структур данных. Посмотреть и потыкать кнопки можно вот тут.
Список визуализированных алгоритмов и структур данных со ссылками под катом.

Я работаю ПМом в небольшой – порядка 50 человек – компании по разработке софта. Данная статья написана исключительно с целью – поделиться своими мыслями по поводу процессов управления людьми в команде и, в идеале, услышать комментарии профессиональных руководителей и разработчиков. Сразу оговорюсь, что я не затрагиваю другие аспекты управления
Поскольку работаю весьма недолго, около года, а до этого был программистом (прошёл все ступени от стажёра до архитектора), то в памяти ещё свежи те ошибки, которые осуществляли мои руководители, после которых, в лучшем случае, на душе становилось пакостно. Опять же, дисклеймер, написано всё это исключительно с целью обсуждения… Итак, начнём.

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

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

В этой статье я постараюсь объяснить о чем, собственно, разговор. Для чего нужно TDD и как его аккуратно использовать.

Что такое TDD в двух словах? — это написание разработчиком тестов до реализации функциональности.
По совету Роя Ошерова разобьем вопрос применимости TDD на два:

• Зачем писать тесты?
• Зачем писать тесты до реализации?

Часто (в том числе и на хабре) всплывает вопрос освещения, особенно «нанотехнологиченого» светодиодного и зачастую говны священных войн «светодиод» против люминисцентных ламп начинают подбурливать. Больше года я уже собирался написать статью о свете, и оно наконец свершилось.
Из этой статьи вы узнаете почему в фотостудиях не снимают с люминесцентными лампами, почему светодиоды до сих пор не захватили мир и стоит ли ими освещать улицы. Поехали!

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

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

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

О чем речь?

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

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

1) AutoMapper
2) BLToolkit
3) EmitMapper

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

Вступление

Приветствую всех.

Люди любят читать. Но не все, и не всё. А то, что любят, не всегда можно найти в магазинах. А если и можно найти, то не всегда это по карману. Из этого следует один элементарный факт: что-то с этим надо делать. Конечно, можно читать с экрана монитора/ноутбука/телефона. Или распечатать и читать в разрозненных, пусть и упорядоченных, листочках. Кроме того (это более затратный вариант, но для любителя чтения он лучше), можно купить специализированную читалку на электронных чернилах. Да, она решает проблему, но… Спустя какое-то время начинаешь скучать по весу настоящей книги, по шелесту перелистывания бумажных страниц, и по кипе других подобных маловажных, но таких приятных сердцу мелочей.
И из этой неприятности тоже есть свой выход. Просто-напросто надо самому сделать нужную книгу.
Осторожно, под катом очень много фотографий.

Преамбула

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

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

И мой ответ — можно. И нужно!

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

Хочу поделиться недавно приобретенным в C# опытом по загрузке и обработке в памяти больших объемов данных. Все нижеуказанное касается Visual Studio 2008 и .Net Framework 3.5.1, на случай каких-либо отличий в других версиях языка или библиотек.

Итак, у нас возникли следующие задачи:
1. Расположить в памяти до 100 миллионов записей, состоящих из строки, длиной 16 символов (уникальный ключ) и двух целочисленных значений, длиной 4 байта каждый;
2. Быстро находить и редактировать запись по ключу.

Натолкнулся в разделе QA на интересный вопрос. Ответ на него заставил написать эту статью как бОлее полный ответ на вопрос «как организовать поиск по множеству параметров, как в Яндекс-маркете, например».

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

Итак, что имеем в «ДАНО»

• Имеем 120 чекбоксов — вариант 1/0
• Имеем 30 «радио» с выбором «да/нет/не важно»
• Имеем 2-3 слайдера для указания диапазона цен/размера чего нить
• Имеем самое главное: 12 млн записей в БД.
• Имеем Select * From tovar Where (wifi=true) and (led=false) and (type=3) and ….остальные параметры …; со временем выполнения близкому к истерике клиента.