High load

http://googlesystem.blogspot.com/2008/01/google-reveals-more-mapreduce-stats.html

The input data for some of the MapReduce jobs run in September 2007 was 403,152 TB (terabytes), the average number of machines allocated for a MapReduce job was 394, while the average completion time was 6 minutes and a half.
Блин, как они это делают... Это же с ума сойти. Любой разработчик в гугле может получить доступ к кластеру, что-то такое посчитать для себя, тут же получит результат, увидеть ошибку, проанализировать, запустить заново и т.п. Наличие такого средства обработки данных - это просто невероятное конкурентное преимущество.

Кадры в брендовых компаниях

Все-таки интересно, откуда такие компании как Гугл берут людей? Ведь их продукт - это их технологии, а значит нельзя просто найти людей с опытом работы с этими технологиями.
Думаю, политика при наборе кадров примерно следующая.
1. Безоговорочно покупаются люди с именем, уже зарекомендовавшие себя. Частенько эти люди покупаются вместе с их компаниями. Эти люди двигают идеи и мысли, занимаются исследованиями, строят концепты, ездят по конференциям и пиарятся.
2. Набирается и обучается свеженькая молодежь. Это инвестиция в будущее, залог успеха и востребованности технологии.
3. Ну и наконец, помимо крутых интересных инноваций, есть и куча рутинной работы. Ее, я полагаю, выполняют обычные середнячковые программисты с рынка труда. То есть что в гугле, что в любой другой компании эта работа приблизительно одинаковая, и никакой рокет сайенс тут не нужен. Тем не менее, компания пытается поддерживать имидж высокотехнологичной и требует от соискателей решения непростых задач. Хотя со временем, конечно, средний уровень понижается, как и в любой крупной организации.

C# decimal

Нарвался на проблему с точностью представления чисел с плавающей точкой. Вот уж не думал, что это может случиться.
Сначала для представления денежных величин начал использовать decimal. Все бы хорошо, но тут я уперся в требования по времени работы программы. Аналитические вычисления занимали по три дня. Прошелся профайлером, обнаружил, что операции работы с decimal, даже такие простые, как, скажем, инкремент на 1, занимают в общей сложности около 15% времени. Ужаснулся. Я понимаю, что decimal реализован программно и не поддерживается инструкциями процессора, но чтобы настолько медленно, я не ожидал! Попробовал пописать простые тесты, делающие в цикле много примитивных арифметических операций с разными типами - decimal оказался медленнее в десятки раз!
Ну и ладно, подумал я, заменю все на double. Это же не расчет зарплаты, в конце-то концов, а аналитические вычисления, порядка точности должно хватить. Но после очень приблизительных прикидок получилось, что погрешность самого математического метода, да погрешность округлений, накопленная за несколько тысяч операций, в денежной интерпретации дает не такие уж и малые величины.

Блин, что делать? Судя по всему, такие проблемы тривиально не решаются.. То есть надо менять математику вычислений. А это явно за рамками разрабатываемого проекта.

деньги

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

проваленные проекты

Интересно, сколько проектов начинается без четких осознанных целей? У меня постепенно складывается впечатление, что чуть ли не большинство. На ITBlogs, кажется, было обсуждение на эту тему - приводилась статистика причин неудачи проектов. Так вот, неопределенность целей побеждает с большим отрывом.

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

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

Some thoughts on modern job market

I acquired some more experience lately both as interviewer and as interviewee :) While interviewing candidates in my company I applied to some companies myself.

1. Lots of programmers look for a job but almost all of them are not good. The percent of the developers I would compare to myself - and I am not the best programmer ever - is very small. The most part of the candidates cannot even pass a quick yes/no test about their preferred technology. I am not even telling about the overall culture of development, about mathematical or computer science skills. It's really hard to find a good developer that is able to solve tasks and make things work.

2. The average salary level is undefined. You can get two absolutely similar offers with the same requirements but the salary will differ twice.

3. 99% of companies are making web sites. I mean just user interface and a very thin layer of business logic. There is a small number of companies that make really interesting and complicated things. And you know what? They don't need standard mainstream developers that have huge experience in popular technologies. They just need good smart people that are able to think. And even if I was very smart while studying in the university - I would forget all of this stuff working as a mainstream developer! And I can't do anything about this - only self-education. This scares me actually - I feel I'm growing foolish. Mainstream is not always good.

4. I have just realized that the first thing the potential employer does after the first glance to your CV is googles -Hi there, guys! - your name, nickname or mailbox account and gathers any information about you. Anyone is able to find a blog of yours, a couple of forums, communities, networks where you spend your time. They can get a pretty good overview of your interests. This is both good and bad.

Задачка

Задали вот мне леххкую задачку на сообразительность. Сколько пятниц 13 бывает в году? Причем ответ должен быть легким, не сложнее, чем поделить одно число на другое. Почему-то мне не показалось, что это такая уж простая задача. Как бы понятно, что если сделать кучу предположений и считать распределение дней по неделям равновеорятным, а каждый месяц - независимым друг от друга, то ответ будет относительно простой. 13 число одного выпадает на пятницу с вероятностью 1/7, а таких событий в году 12 штук, то вероятность выпадения 13 числа на пятницу во всем году 12/7. Или 12 раз в 7 лет. Но так считать ведь неверно! Месяцы не независимы! Если в одном из них выпало какое-то событие, то во всех остальных достоверно известно, что именно выпадет! То есть нельзя просто умножать на 12. Да и вообще, есть же еще вискососные годы.. Полагаю, что просто так не посчитаешь, надо тупо высчитывать по очереди все дни в пределах одного периода, где период - общий для периодов недель и високосности. То есть надо знать, какие там годы вискосносные, а какие нет.. Короче, вообще нетривиально. В уме не посчитаешь.

П.С. Решение я нашел. У мирового разума.

What sex is computer system?

Я почему-то всегда думал, что компьютер - это "она". Ну как будто бы это не "компьютер", а "машина". Да и вообще, это получается как-то случайно: "Что она пишет?", "И что это она сейчас делает?". Это настолько естественно, что я даже не задумывался на эту тему. Типа как в английском, все корабли и судна, в том числе очень большие воздушные или космические - "she". Из уважения, что ли? Или, как бы это так сказать, позыв души выразить, как много сил уходит, чтобы, мм, добиться от этой штуки ожидаемого?

А тут вот появилось еще одно наблюдение - девушки имеют тенденцию говорить "он".

Что-то за этим все-таки стоит. Надо Фрейда почитать.

Compile-Time Attributes

Вот ведь е-мое, это все только в разработке, оказывается.

http://research.microsoft.com/specsharp/papers/krml135.pdf

Compile-Time Attributes

Я вот тут вдруг подумал, что валидацию параметров методов надо бы делать декларативно.

Самая большая ерунда в том, что самому такую ерунду написать проблематично - ведь для разбора атрибутов придется лазить в рефлекшн, да еще и писать что-то вроде менеджера вызовов, который будет применять логику до вызова метода и после него. Тем более такие штуки, вроде бы, уже есть: http://www.codeplex.com/ValidationFramework. Не думаю, что они очень быстрые, эти штуки.

Надо чтобы компилятор сам впихивал в начало метода соответствующий код. Неужели такого еще нет? Вот блин.