Объявляется маленький challenge. Всего одна малюсенькая, простенькая задачка и неделя времени.

Пусть дан тип typeof(List<>).
Положив первый параметр этого типа равным typeof(string) мы получим нечто, что можно будет сохранить в переменную типа typeof(IList<string>):

Assert.IsTrue(
    typeof (IList<string>).IsAssignableFrom(
        typeof (List<>).MakeGenericType(typeof (string)))
    );

А теперь, собственно, задачка!

Дан некоторый тип T, только что загруженный из сборки. То есть это либо не generic, либо generic с неопределенными еще параметрами типа. Например, typeof(List<>).

Дан другой generic тип I, только что полученный методом GetType(). То есть это generic, у которого все параметры типа определены. Например, typeof(IList<string>).

Задача — путем определения параметров типа T получить тип, который будет совместим по присваиванию с I, либо сказать, что это невозможно, либо сказать, что существует более одного способа это сделать.

Победителем этого конкурса станет тот, у кого исходник окажется короче. (Более точно — у кого в исходнике решения будет меньше лексем-идентификаторов, чем у других).

Конкурс длится неделю. Время пошло! Комменты скрыты. :)

UPDATE: Если доопределить параметры можно более чем одним способом, можно не доопределять, а просто сказать, что способов много. (текст выше подправлен).

1. Попробую собрать аггрегированную информацию по размеру зарплат в нашем управлении разработки. Самому уже надоели слова "выше среднего по рынку" и "договоримся". То есть мы, конечно, договоримся, но некоторую информацию все таки хорошо бы предоставлять, чтобы кандидатам было от чего отталкиваться. Всем поучаствовавшим — спасибо за последнюю каплю. :-)

2. Маньяки. Вакансия является ответом на сложившуюся вокруг меня реальность. А реальность такова, что ко мне на собеседования приходят массово люди, которых я видеть в своей команде в данный момент не хочу. И всех их кое-что объединяет.
Они не интересуются программированием, но хотят программировать. Они, программируя на языке C#, не знают его. Они не умеют вести околопрограммистские рассуждения — конечно, они никогда этого не делали! Им ведь все это не интересно!

Цель публикации вакансии проста — изменить реальность. Хочу, чтобы к нам на собеседования шли те, кому как минимум интересно. А если в толпе попрущихся к нам маньяков будет ещё какой-то массовый недостаток (например, все как один будут неадекватами, фигачащими интересную и прикольную никому не нужную ерунду), я ещё что-нибудь придумаю. :-)

В Екатеринбурге в управление разработки СКБ Контур требуется маньяк.

Маньяк вовсе не обязательно должен иметь 5 лет опыта работы разработчиком, и ему не обязательно знать WPF, WCF, ASP, DDD и прочие TLA. Но если он о них слышал хотя бы краем уха — хорошо.

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

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

Маньяк должен уметь разговаривать и писать на русском языке. Мы много общаемся и если человеку сложно выразить свои мысли словами — нам с ним будет тяжело (впрочем ему тоже не сладко). Естественно, слушать и понимать других — тоже обязательно. Если неприятный, нехороший и гадкий собеседник приводит логичные и правильные аргументы — маньяк обязательно эти аргументы рассмотрит несмотря их происхождение.

Маньяк должен быть знаком с языком C# и с основами .NET Framework — с этим добром ему придется у нас работать. Мне даже немного стыдно за этот пункт, поэтому я поясню. Тут у нас никто не будет никого учить языку C#. А раз его все равно нужно будет изучать самостоятельно, то для маньяка не должно быть проблемой сделать это дома, заранее. Взять и потратить пару-тройку вечеров, чтобы освоить основные вещи.

Это, конечно, не все наши требования к маньяку, но основные.

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

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

Географически, к тому времени как маньяк найдется, мы наверняка уже будем располагаться в новом офисе на ул. Народной Воле 19А. Офис такой новый, что на Google maps его даже ещё нет .



Если вдруг вы искомый маньяк — пишите на pe@skbkontur.ru. Если у вас есть знакомый маньяк — дайте, пожалуйста, ему ссылочку на этот пост.

Раз уж некоторые во френдленте начали, то и я расскажу эпизодик из нашей жизни.

База отдыха, корпоративно-отдыхательно-деловое сборище всех подряд. Все пришли на обед в столовую и толкутся в маленьком закутке с вешалками — снимают верхнюю одежду. Центральную часть закутка занимает вешалка на колесиках.
Приходят разработчики и со словами "а чего мы тут толпимся" выдвигают вешалку на колесиках из закутка. Всем становится комфортнее.
Рядом Сабитов (один из тру-sales-people): "Вечно бы вам разработчикам что-то оптимизировать... Вот я бы её... Продал бы!"

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

Правильный ответ: В стек-трейсе будут строки (1) и (3) и не будет строки (2).

class ThrowTest
{
 void ThrowException()
 {
  throw new Exception(); // (1)
 }

 void RethrowException()
 {
  try
  {
   ThrowException(); // (2)
  }
  catch
  {
   throw; // (3)
  }
 }
}

* This source code was highlighted with Source Code Highlighter.

Внутри catch у исключения в стек-трейсе ещё числятся "(1) и (2)", но сразу после throw (2) заменяется на (3).

А победил в опросе ответ "(1) и (2)". Что интересно, именно так throw работает в языке Java. С какого перепуга в .NET отступились от проверенного джавой решения — не понятно. Кстати, я думал так же, пока не проверил.

На втором месте ответ "только (3)". Это люди, которые не осознают разницу между throw e; и throw;. А надо бы.

На втором же месте загадочный пункт "только (1)". Чем руководствовались эти люди — для меня загадка.

На третьем месте пункт "(1), (2), (3)". Мечтатели-идеалисты. Если бы я дизайнил CIL, я бы постарался сделать именно так. Почему в Java не так? Может кто-то видит тут какие-то скрытые противоречия? Я вот не вижу. :(

За остальные пункты не голосовали вообще.

Я было попытался найти официальный источник, который описывает как должно быть, но ни в стандарте CIL, ни в стандарте C# не нашел. Даже от отчаяния пошлялся по MSDN — безрезультатно. Где ещё можно посмотреть даже и не знаю.

PS. Всем спасибо за честность. ...или за лень. :-)

А ну-ка, не подглядывая в спеку и не проводя экспериментов, попробуйте дать правильный ответ!

class ThrowTest
{
 void ThrowException()
 {
  throw new Exception(); // (1)
 }

 void RethrowException()
 {
  try
  {
   ThrowException(); // (2)
  }
  catch
  {
   throw; // (3)
  }
 }
}

* This source code was highlighted with Source Code Highlighter.

Вызываем RethrowException.

Опрос #1468664 Как работает throw
Открыт: Всем, подробные результаты видны: Всем, участников: 20

Какие строки будут присутствовать в стек-трейсе исключения?

Я надеюсь, настройка соединения wifi уже вошла в список самых больших ошибок usability? WEP /WPA / WPA2 / Wep Key 1 / Wep Key 2 … / Wep pass phrase / HEX / Ascii.

С кем они вообще разговаривают?!

1. Возможность инжектить зависимости от коллекций.
2. Ленивая работа с зависимостями.
3. Возможность регистрировать один объект сразу на роль нескольких сервисов.

Почему-то для 2 и 3 нет нормальных способов в StructureMap out-of-the-box.
Хотя имея его исходники они несложно добавляются, зная даже без их модификации.

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

PPS. Если что, по оси Х - время в днях, точки по оси Y — количество ещё незавершенных задач из известных на данный момент. Жирная синяя точка — это сегодня.

PPPS. Это за нас наши роботы строят, это мы не сами, естественно :-)

Как все, наверное, знают, я веду практики по программированию у второго курса. Поэтому мне приходится вести довольно много очевидных разговоров о программировании. И, как говорится, "Ой! Не могу больше терпеть! По-о-оказываюсь!" (с) Большой Ух.

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

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

В 80х годах Бертран Мейер придумал явно выписывать строго формализованные контракты модулей. 20 лет спустя до продакшена еле-еле добираются .NET Framework 4 с его пространством имен System.Diagnostics.Contracts и с соответствующим расширением компилятора C#. Где-то там же подползает ещё одна реализация идей Мейера — PEX — генератор тестов по описанию контракта.

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

А ещё какое-то представление о контракте есть у человека, использующего класс. Это представление обычно базируется на интуиции и именах класса и его членов. Назовем такое представление интуитивным контрактом.

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

Так-то!

В общем то я не удивлен, что Eclipse ищут, а IDEA пиарят.



Но по ссылке можно получить и более интересные данные. Например, оказывается, что IDEA просто ненормально популярна в Индии.
Хорошенькая рекламма: Среда разработки IDEA! Почувствуй себя настоящим индусом!

Интересная задача — это сложная задача.
Где обычно обитают интересные и сложные задачи?

Я сформулировал одну эвристику, которая позволяет находить интересные сложные задачи. И да, на нее тоже можно медитировать! Итак, вот она:

"Если у вас чего-то много, то у вас есть интересная, сложная задача." :-)

Чтобы медитировалось плодотворнее, вот вам ряд примеров:
1. Если у вас много пользователей, которые ломятся в ваше веб-приложение — у вас интересная и сложная задача создания масштабируемого, отказоустойчивого веб-приложения.
2. Если у вас много html страниц в интернете, то перед вами интересная, сложная задача индексирования этих страниц и поиска по ним.
3. Если у вас фреймворк, который очень активно используется (много классов-пользователей), то перед вами сложная и интересная задача разработки гибкого, лаконичного и очевидного интерфейса, который сохраняет обратную совместимость и все такое прочее.
4. Если у вас много форм налоговой отчетности, то перед вами сложная и интересная задача написания движка рендеринга этих форм и проверки контрольных соотношений, сокращающего до минимума время разработки еще одной очередной формы.
5. Если у вас много функциональных тестов, то перед вами сложная и интересная задача создания фреймворка, на базе которого можно будет легко и непринужденно клепать новые тесты, которые не будут падать по всяким глупым, несущественным причинам. А даже если и будут, то будут при этом давать максимум информации, необходимой для понимания причин падения.
...

Ну, вы меня поняли... :-)

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

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

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


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

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

Что касается фактов, то они просто нужны для того, чтобы на них можно было строить те самые рассуждения.

Вот и получается:
1. Факты и примеры рассуждений.
2. Близко, но при этом ново и небанально.

Посмотрим насколько доклады будут соответствовать моему критерию. :-)

Сегодня я просто на стуле подскочил, когда читал пост про то, как стать театральным критиком!

Натурально, пост про недавнюю дискуссию о микрооптимизациях в программировании! :)

За два выходных я сделал с рабочим проектом то, о чем мечтал уже года три. Одна из задач - создание плагина - решалась немного уродски. Многословно и слишком жестко. Это в общем-то особо не мешало, но я каждый раз морщился, когда видел такой код. А плагинов у нас, надо заметить, более ста штук. Собственно проблема была в том, что надо было затронуть около 200 классов накопившегося наследия. Чтобы не утонуть в конфликтах, надо было очень хорошо выбрать время для этого рефакторинга. А чем дольше я тянул, тем плагинов становилось больше, и рефакторинг становился все ужаснее.

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

Итак, два дня, ноутбук, VPN, и, кажется, я горд собой. :-)

Всех с праздником, друзья!

P.S. Чтобы не подохнуть от рутины, я освоил средство записи временных макросов в студии. Удобно!

Народу, которому понравилась игра Зельеваренье посвещается:

Ну хорошо, не нравятся вам микрооптимизации, основанные на методах расширения, вот вам микрооптимизация без них и без ущерба понятности.

Сценарий 3. Ленивая инициализация свойства класса.

// Стандартный код
public Foo Foo
{
 get
 {
  if (foo == null)
   foo = CreateFoo();
  return foo;
 }
}

// Микрооптимизация
public Foo Foo { get { return foo = foo ?? CreateFoo(); } }

* This source code was highlighted with Source Code Highlighter.

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

Сценарий 1. Надо вернуть из метода результат поиска или кинуть исключение, если не нашли.

// Стандартный код
Foo foo = Find();
if (foo == null) throw new Exception();
return foo;


// Лекарство
public static T ThrowInsteadOf<T>(this Exception e)
{
  throw e;
}

//После лечения
return Find() ?? new Exception().ThrowInsteadOf<Foo>();


Сценарий 2. Надо проверить, реализует ли объект интерфейс, и если реализует, то вызвать у него метод этого интерфейса.

//Стандартный код
IFoo foo = obj as IFoo;
if (foo != null) foo.DoFoo(bar);

//Лекарство
public static void If<T>(this object obj, Action<T> act)
{
  if(obj is T) act((T)obj);
}


//После лечения
obj.If<IFoo>(foo => foo.DoFoo(bar));

//а иногда и так
obj.If<IFoo>(ProcessFoo);

* This source code was highlighted with Source Code Highlighter.

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

И знаете что? Глядя на аудиторию, мне пришлось на ходу все переделывать и в конце концов импровизировать.
Вот забавно, сколько я помню своих домашних приготовлений к подобным беседам, всегда потом получается импровизация. :-) Не без элементов домашних заготовок, но импровизация.