деньги

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

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

Интересно, сколько проектов начинается без четких осознанных целей? У меня постепенно складывается впечатление, что чуть ли не большинство. На 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. Не думаю, что они очень быстрые, эти штуки.

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

WTF?

private const FileOptions requiredOptions =
FileOptions.Asynchronous | FileOptions.DeleteOnClose | FileOptions.Encrypted |
FileOptions.RandomAccess | FileOptions.SequentialScan | FileOptions.WriteThrough;

private void someMethod(FileOptions options)

{

if ((options & ~requiredOptions) != FileOptions.None)

throw new ArgumentOutOfRangeException("options");

}

Нашел еще один интересный performance-bug

1000 объектов DateTime в Hashtable, обрабатываются раза в 3-4 медленнее, чем 1000 объектов в Generic Dictionary. Вот такая ерунда. Время экономится на операциях boxing-unboxing.

Автоматизация тестов

Как же часто нормальное юнит-тестирование спасало проект и сохраняло мне часы и дни героических боев с багами! Сейчас тесты, наряду с любимым инструментом для рефакторинга, кажутся такими естественными, неотъемлемыми атрибутами процесса программирования, что без них чувствуешь себя буквально без рук. Невероятно раздражаешься, когда приходится лишний раз открывать тормозной отладчик. Гадость в том, что не все поддается автоматическому тестированию. Базы данных еще более-менее побеждаются всяческими там фейками (fake), моками (mock) и прочими ухищрениями, но вот при интерфейс пользователя - полностью ручная работа.

Есть много проблем, которые возникают при попытках автоматизировать UI. Перво-наперво, почему это надо делать?

1. Заказчик, в подавляющем большинстве случаев, мыслит именно в категориях интерфейса. То есть все, что он себе представляет - это внешний вид системы и ее реакцию на действия пользователя. Естественно желание сделать нечто, что сразу же говорит разрабочтику, соответствует результат работы этим требованиям или нет.
2. Если все нижние слои системы покрыты тестами, то UI получается самым слабым звеном. В нем чаще всего появляются и сложнее всего ищутся ошибки. А тратить 20 минут и лезть в какой-нибудь ASP.NET-отладчик, который съест полтора гига оперативки, ради того, чтобы узнать, что какой-нибудь там дропдаун (dropdown) не восстановил состояние из вьюстейта (viewstate), согласитесь, раздражает.

Теперь, какие же все-таки возникают проблемы, помимо самой технической нетривиальности?

1. Там приходится программировать. Это утверждение не кажется таким уж глупым, если учесть, что отделы QA укомплектованы не программистами. QuickTestPro предлагает писать скрипты на бейсике, различные NUnit-библиотеки для ASP используют прямо C#. Кроме того, для каждого теста надо готовить исходные данные, для чего может понадобиться соответствующий навык, чаще всего SQL.
2. Эти тесты ужасно долго работают. В большинстве случаев системы тестирования позволяют записать примитивный макрос - последовательность движений и кликов мышки, нажатия клавиш и т.п. То есть для тестирования веб-приложения система открывает браузер, ходит там по нему, кликает и т.п. Таким образом, это не дает немедленного фидбека разработчику так, как это делают юнит-тесты.
3. Соответственно, тестирование нельзя запустить в фоновом режиме на рабочей машине. Приходится еще и выделять отдельный компьютер. Иногда бывает проблемой.
4. Поддержка написанных тестов в рабочем состоянии - головная боль тестеров. Интерфейс пользователя меняется быстро. В ASP.NET, скажем, стоит положить контрол на страничке в другой контейнер, как его клиентский ID кардинально изменится. Тест поломается, а выполняется он долго, то есть чинить его тоже достаточно долго и неприятно. В итоге все сведется к тому, что тестер плюнет на все, самостоятельно пробежится по страничкам и на глаз посмотрит, что "вроде все правильно".
5. Чувствуется большой недостаток в общении между разработчиками и тестерами. То есть по идее, исходя прямо из тербований заказчика, можно было бы изначально договориться о том, какие элементы управления понадобятся на данном экране. Потом на экран попросту сверху вниз слева направо добавляются все необходимые кнопки, которые пока ничего не делают. На этом этапе тестеру уже есть над чем работать.

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