Говорят, что идеи ценятся дороже любых драгоценностей и предметов искусства и при грамотном использовании могут принести миллионы долларов. Говорят, что если к вам в голову пришла интересная идея, то её нельзя никому рассказывать, а надо найти богатого инвестора и продать идею ему за большие деньги. Говорят, что идею надо обязательно запатентовать, иначе богатые инвесторы украдут идею и не заплатят денег. Говорят, что те кто так сделал — сейчас сказочно богаты, купили себе остров и живут там как в сказке. Говорят… А кто говорит-то? Да все вокруг! Друзья, коллеги, знакомые, родственники. А так ли это на самом деле?

В некоторых проектах достаточно часто возникает необходимость в хранении данных, объем которых уже нельзя назвать маленьким, но в тоже время использовать какую-либо СУБД слишком накладно из-за сложности развертывания приложения. И тут на помощь приходит такая прекрасная вещь как SQLite – компактная встраиваемая база данных.

Для тех, кто пишет с использованием платформы .NET приятным моментом станет наличие

Добрый день!

Как представитель проекта Лекториум рад сообщить — мы опубликовали весь архив Computer Science клуба.
Кроме того, почти год назад мы организовали запись всех лекций на хорошие камеры и микрофоны.
А в этом году планируем подключить вебинары.


Большинство лекций читается на русском языке. Все записи снабжены презентациями и описаниями.

UPD. Кратко. Старые лекции в плохом качестве, а новые с 2010 года с хорошим звуком и в 720p.
UPD 2 Расширили канал, видео грузится теперь без проблем.

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

Постановка задачи

Буквально несколько дней назад Eric Lippert на своем блоге Fabulous Adventures In Coding опубликовал очень простую, но занимательную задачку:

Есть дерево, заданное с помощью класса Node, в котором есть Children с теми же самыми Node и какой-то Text (чуть ниже приведу код класса). Необходимо сгенерировать строку такого вида (включая переносы строк):
Использовать нужно юникодовые символы "│ ├ ─ └" (вспомним старые добрые картинки с псевдографикой). Цель, которую поставил себе Эрик — выяснить, какие предпочтения будут сделаны при составлении решения: рекурсивное (так как дерево), более быстрое или более читабельное.

Возможно, многие из читателей задавались вопросом, как людям удаётся собирать кубик Рубика 3×3 за 7 секунд. Если даже предположить, что рекордсмену сильно повезло, то таблица мирового рейтинга по среднему из пяти результатов уже не оставляет сомнений: если больше 80 человек в среднем укладываются в 12 секунд, очевидно они что-то знают. В этом кратком обзоре я постараюсь приоткрыть секреты скоростной сборки. Сразу оговорюсь, что после прочтения этой статьи вы не станете чемпионами: здесь приведены только основные моменты и ссылки на более подробную информацию. Кроме того, даже после изучения метода полностью вам потребуются долгие тренировки для достижения хороших результатов. Зато вы получите неплохое представление о том, как это делается, и при желании будете знать, куда двигаться дальше. Я думаю, при достаточной усидчивости после нескольких месяцев тренировок многие смогут достичь среднего результата в районе 30 секунд.

Эта статья с одинаковым успехом может быть отнесена к блогам ".NET", «Open source» и «Я пиарюсь». После того. как я написал материал, стало ясно, что больше всего в ней «Open source»… Просьба сильно не бить, если я ошибся.

Итак, ниже пойдет рассказ о моем полуторагодичном опыте разработки библиотеки SevenZipSharp с открытыми исходниками, выложенной на CodePlex в феврале 2009. Эта библиотека — обертка над 7-Zip, позволяющая с легкостью его использовать в .NET.

Меня дико бесит OnPropertyChanged. Он требует передачи ему строки с именем идентификатора… Мало того, что такой код не верифицируется компилятором, так еще и никакого Intellisence — тайпи весь идентификатор от начала до конца… А если опечатаешся — так проглотит и во время выполнения. Вобщем, нехорошая вещь. Но в MVVM без нее никуда, как и в WPF без MVVM.

Последняя проблема худо-бедно решалась вот таким костылем, содранным отсюда, который вызывался из OnPropertyChanged:

[Conditional("DEBUG")]
[DebuggerStepThrough]
public void VerifyPropertyName(string propertyName)
{
  // Verify that the property name matches a real, 
  // public, instance property on this object.
  if (TypeDescriptor.GetProperties(this)[propertyName] == null)
  {
    string msg = "Invalid property name: " + propertyName;

    if (this.ThrowOnInvalidPropertyName)
      throw new Exception(msg);
    else
      Debug.Fail(msg);
  }
}


И вот сегодня я совершенно случайно нашел красивый способ избавится от него.

Динамические вызовы: что это и зачем?

Думаю, для каждого разработчика, работающим на статических языках программирования, иногда возникала необходимость прибегнуть к динамическим вызовам — вызвать метод чего-то, о чем пока еще ничего не известно. Или получить какое-то свойство у какого-то объекта, о котором будет известно только в run-time.

Это иногда используется в алгоритмах, основанных на так называемой «утиной типизации» (duck typing):

Если что-то выглядит как утка, плавает как утка и крякает как утка, то это, вероятно, утка и есть.

В данной статье я хотел бы рассмотреть основные доступные в Microsoft .NET 4.0 способы, сравнить их производительность и синтаксис.

Если вы используете ReSharper, то вы, наверняка, знакомы с его подсветкой "Possible 'NullReferenceException'". В этой статье я кратко расскажу об анализаторе, который выводит предупреждения такого рода, и о том, как ему помочь делать это лучше.

Сразу рассмотрим пример:

`public string Bar(bool condition)
{
  string iAmNullSometimes = condition? «Not null value»: null;
  return iAmNullSometimes.ToUpper();
}

* This source code was highlighted with Source Code Highlighter.`

ReSharper справедливо подсветит iAmNullSometimes во второй строке метода с таким предупреждением. Теперь выделим метод:

`public string Bar(bool condition)
{
  string iAmNullSometimes = GetNullWhenFalse(condition);
  return iAmNullSometimes.ToUpper();
}

public string GetNullWhenFalse(bool condition)
{
  return condition? «Not null value»: null;
}

* This source code was highlighted with Source Code Highlighter.`

После этой операции предупреждение пропадает. Почему так происходит?

Как разработчик, вы сидите на золотой жиле. Вы осознаете это?

Нет, серьезно, на @#$% золотой жиле! Никогда в истории не существовало возможностей так легко создать что-то с нуля, с маленьким или отсутствующим начальным капиталом и маркетинговой моделью, ограниченной только вашим воображением.

Подумайте о крупнейших сайтах, которые вы постоянно посещаете: Facebook, Twitter, Flickr, Foursquare, или даже Google — все они были созданы разработчиками, у которых была лишь идея. Было ли это легко? Черт, нет. Но это могло быть сделано только в наше время. Так, черт побери, почему вы просиживаете день за днем, работая на кого-то?

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

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

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