Здесь живёт Кучерявый

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4802695

Начиная с 1.6.0.12. Ура, товарищи. Не прошло и пяти лет.

Ничего сложного в этом нет. Главное психологически себя перебороть.

Похоже, процесс компиляции потомка успешно инициирован. ETA: 9 месяцев.

Через полтора часа.

Долгое время я был противником SWT и всячески старался использовать только Swing-приложения. Pure Java, входит в стандартную поставку и всё такое.

Вчера я наткнулся на особенность свинга, которая разом перекрыла все мои аргументы в его пользу. Началось всё с того, что я захотел организовать себе на работе двухмониторную конфигурацию. Двухголовых видеокарт почему-то не оказалось, а очень хотелось, поэтому я погуглил и нашёл для себя Xdmx (distributed multihead X). Работает он просто - поднимаем на произвольном количестве машин иксы с произвольным количеством мониторов, после чего на управляющей запускаем Xdmx-сервер, к которому будут подключаться запускаемые приложения, а он предоставляет им мега-дисплей любой конфигурации, части которого отображаются на мониторах. Важно, что количество дисплеев не ограничено ничем, кроме вычислительных способностей управляющей машины и сети между ней и слэйвами.

Так вот. Всё хорошо и замечательно, настроил я себе два монитора, один на самой управляющей машине, второй на другой и стал запускать-пробовать всякие приложения. Работает всё, даже без ощутимых задержек, кроме Swing'а, который конечно всё показывает, но делает это так медленно, что пипец. Даже примитивные клики мышкой по чекбоксам отрабатываются секунд по 5. Причём насколько я понял из гуглинга, эти тормоза можно пофикстить только кардинальным изменением архитектуры Java2D, которая сейчас основана на том, что весь рендеринг делается программно явой, после чего графической системе отдаётся готовое изображение.
Думаете у меня кривые руки? Попробуйте сами - запустите удалённую X-сессию на localhost и запустите в ней, например, jconsole, отображающую информацию о себе.

В общем Swing пошёл лесом, а вместе с ним и IDEA, которая просто неюзабельна. Привет, Eclipse. Ну может оно и к лучшему.

1. Запускаем свою любимую Java-IDE.
   
2. Ищем регексом по всем исходникам библиотек "throw new .*e\.getMessage\(\)\)"
   
3. Определяем авторов этих строк
   
4. Вырываем им руки, чтобы больше так не писали.
   

Среди библиотек моего проекта таких случаев нашлось 189.

Update: а гугл знает 155 тысяч таких случаев.

Ё-моё! Вчера вышла Fallout 3! Срочно все в магазины

Часть первая, group by

Имеем табличку 't' с колонками 'a' и 'b'. Выполняем запрос:

select a, b from t group by a;

На всех базах ошибка, а mysql выполняет. Почему? Потому что mysql - дерьмо
Этот запрос, конечно, некорректен. Потому что мы группируем записи с одинаковыми значениями в колонке 'a', но не сказали базе, что при этом делать с колонкой 'b' у группируемых записей. К ней нужно применить агрегатную функцию или добавить её в group by. Mysql же в такой ситуации использует значение первого сгруппированногоо кортежа.

Часть вторая, distinct

Что делает distinct? Фильтрует результат выборки, возвращая только уникальные кортежи.

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

И тут же нас подстерегает большая засада. Обычно считается что список можно отсортировать за n*log(n). Ну вот это на самом деле неправда. Потому что такая формула не учитывает стоимость сравнения элементов. А именно на ней можно продолбать тонну перфоманса.

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

select distinct a.id, a.title, a.content
from favorites f join article a on f.article_id = a.id where f.user_id in (...);

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

В моём случае происходило сравнение между собой 500 кортежей с одной и той же записью и запрос занимал 3 секунды.

Кстати, если вы используете mysql, то можете заметить, что такой же запрос выполняется заметно быстрее чем на постгресе. Знаете, почему? Потому что этот долбанный mysql при сравнении blob' ов учитывает только первые 256 байт. В отличие от постгреса, который честно сравнивает их целиком. Это примерно как считать хэш от первых двух символов, чтобы быстрее было. Мда.

Решение элементарно: вместо всех записей выбрать их id, а ещё одним запросом вытащить записи с такими id:


select a.id, a.title, a.content from article a where a.id in(
select distinct a.id from favorites f join article a on f.article_id = a.id where f.user_id in (...)
);


Как заметил alexshubert, вот так даже проще:

select a.id, a.title, a.content from article a where a.id in(
  select distinct f.article_id from favorites where f.user_id in (...)
);

В моём случае после такого изменения запрос ускорился в тысячу раз, с трёх секунд до трёх миллисекунд. Кстати в таком виде mysql уже уступает постгресу.

Нашёл странное: http://talkee.ru/

Туда подходят логины/пароли от аккаунтов на hh.ru. Для чего надо - пока не понял. В гугле не гуглится. Видимо этого проекта официально ещё нет :)

Домашняя страница соискателя, приславшего нам резюме. Плачем :)

Сломал яндекс-деньги :( Платёж на 200 рублей, 5% комиссия за перевод, итого у яндекса получилось 250. Упс.

Зачем они это делают?

Бабло

Как измерить программиста

В название этого раздела я вынес заголовок обсуждения с форума Xpoint.ru, в котором (обсуждении) происходило обсуждение данной темы.

Работа программиста - не количественная. Это не мешки таскать, где потаскал N мешков - тебе f₁(N) денег, сумел продать M единиц продукции клиентам - тебе f₂(M). Мерять количество кода бесполезно, потому что лучше если функционнальность реализована за как можно меньшее его (кода) количество. Считать исправленные баги тоже бессмысленно, потому что тогда программисты сами будут вносить их в код, а потом исправлять. Штрафовать за баги тем более нельзя, потому что количество багов пропорционально функциональности приложения. Даже ставить зависимость от количества заработанных с помощью программы денег нельзя, потому что от программиста это зависит в наименьшей степени. Как вы, например, померяете програаммиста, который пишет мало кода, зато постоянно помогает другим в случае возникновения проблем? Или того, который постоянно рассказывает на обеде интересные истории, повышая настроение остальных?

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

Нейтральным способом может быть введение понятия уровней (Beginner, Advanced, Expert и т.п.) с чётким разграничением зарплат, полномочий, обязанностей и требований, чтобы люди понимали, почему они получают столько сколько им платят и что им надо научиться делать, чтобы продвинуться выше.

Премии

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

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

Следующий важный момент заключается в невыдаче премий. Если команда работала-работала, а потом половине премию выдали, а другой нет, то те, кто остался без премии будут расстроены. Если же премии выдавать поровну, то будут огорчаться наиболее сильные члены команды. У них просто будет пропадать желание работать и они будут опускаться до среднего уровня (всё-равно ведь бОльшего бонуса им за жто не дадут).

Ещё одно. Наличие общей суммы премий, которая делится среди членов команды, провоцирует конкуренцию, вместо объединения людей с единой целью.

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

Не бабло

Из всего вышесказанного следует (а может мне только кажется что следует), что с материальными поощрениями лучше не связываться. Теперь рассмотрим нематериальные. Кстати. Мне вообще не нравится слово поощрение. Не надо поощрять (исходя из предположения что программисты и так стараются работать хорошо). Надо улучшать условия и благодарить.

Эти способы я разделил на категории.

Плюшки

В противоположность пряникам, обычно используемым в переносном смысле, плюшки я использую в прямом. Если программист проголодался, он пойдёт на обед (сколько в вашей компании люди тратят на обед? Час? Полтора?). Но если он занят интересной задачей и под рукой окажется что-нибудь съедобное, то скорее всего он никуда не пойдёт, а перекусит, не отвлекаясь от задачи.

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

Рабочее место

Основную часть своего рабочего времени программист проводит за компьютером. И крайне важно как оборудовано его рабочее место. Достаточна ли производительность железа? Удобны ли в использовании программы, необходимые ему (программисту) в работе? Не мешает ли ему антивирус (да будет вам известно, что запущенный антивирус может увеличивать время сборки программы до трёх раз)? Не шумят ли рядом менеджеры, постоянно отвлекая его от работы? Не сломал ли злобный админ доступ ко внешним svn-серверам, установив корпоративный http-прокси?

Всё вышеперечисленное (и многие другие мелочи) могут катастрофически влиять на настроение и общую продуктивность программиста. Как правило программист сам говорит, чего ему не хватает.

Режим работы

Скажите честно, что в вашей компании скажут программисту, если он захочет приходить на работу с 14:00 до 22:00, потому что он привык поздно ложиться и вставать? Нет? А почему? Зачем вам нужно чтобы он в 10 утра был в офисе, невыспавшийся и мрачный? Я знаком с людьми, которые утром, после того как проснулись, залезают на час-полтора в интернет, чтобы почитать новости/блоги/башорг/whatever, после чего едут работать. Знаете что произойдёт если им скажут раньше приезжать? Они будут читать башорг на работе, потому что вы отняли у них возможность делать это до неё.

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

Коммуникация

И, наконец, самое главное - люди, с которыми программисту приходится общаться. Есть ли в команде аналитик или программисты сами бегают по офису и пытаются выяснить, что же они должны написать? Не запирает ли их в офисе охрана, когда они засиживаются до поздна? Знают ли они к кому обращаться когда им чего-то не хватает? Не заставляют ли их заниматься бесполезной работой (кстати, один из наиболее сильно демотивирующих факторов)? Не давит ли на них руководство, продавшее несуществующую фичу, которому ещё вчера надо чтобы фича была?

Итого

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

P.S. Мне в комментариях к прошлому посту сообщили что я ни черта не понимающий в экономике романтик, поэтому всё вышесказанное к реальности скорее всего относится слабо.

На моём компьютере установлена ровно одна закрытая программа - IntelliJ IDEA. И делает она это только потому, что мне в ней удобнее чем в Eclipse. Перестанет мне в ней быть удобно (или кто-нибудь допилит Eclipse до вменяемого состояния) - и не будет она больше стоять (и, если честно, я буду только рад).

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

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

Свобода выбора

Обычно бывает так: вы пользуетесь открытой программой, но неожиданно натыкаетесь на баг/отсутствие жизненно необходимой вам фичи. Дальше есть несколько возможных вариантов:

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

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

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

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

А где же прибыль?

На чём зарабатывать деньги, спросите вы? Я отвечу: на чём угодно, кроме продажи софта. Посмотрите на Google, Yahoo, Sun, Mozilla, Apache. Они не продают софт. Однако имеют большое влияние в софтверной отрасли (и от нехватки средств не страдают). Опенсурс - это не про прибыль. Это про деланье мира лучше, а людей счастливее. Продавайте рекламу, поддержку, услуги - что угодно. Делайте закрытый софт для себя, только не надо его продавать.

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

Опять же, основная масса программистов хочет иметь возможность похвастаться своей работой. Они хотят показать некоторую программу, потыкать кнопку и сказать - а это я сделал. Что может быть лучше чем возможность показать результаты своего творчества всему миру? Радостный программист - программист, которому есть что показать. К тому же открытая разработка способствует повторному использованию, т.к. программисты не сидят каждый в уголке со своей библиотечкой, а активно ими между собой обмениваются.

Мораль

Разработчики, убеждайте своих работодателей пользоваться открытыми программами и разрабатывайте новые открытые программы, если это не межает бизнесу компании. Очень бывает обидно разработать классную библиотечку/компонент/whatever, а потом сменить работу и выяснить, что придётся писать его повторно, т.к. договор с первым работодателем не даёт вам никаких прав на код, который вы написали.

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

Ушёл патчить Django.

В интернете существует такая неприятная штука как XSS (Cross Site Scripting). Заключается она в том, что на сайте может присутствовать уязвимость, благодаря которой злоумышленник может подсовывать другим пользователям Javascript, который выполняется на странице сайта как будто этот скрипт самого сайта. И чаще всего такую уязвимость используют для cookie theft (похищение cookies пользователя в целях последующих нехороших действий от имени этого пользователя. Я не буду приводить пример такой атаки, его легко найти с помощью вашего любимого поисковика. Основная причина благодаря которой возможно похищение cookies с помощью XSS - тот факт, что из Javascript есть полный доступ к cookies относящихся к странице, на которой запустился этот Javascript.

И вот, оказывается ещё в IE6 SP1 появилась защита от такой атаки. Суть защиты состоит в том, что сервер помечает, какие cookie предназначены для самого сервера. Cookie, помеченные таким образом, из Javascript попросту не видны.

Подробное описание этой функции можно прочитать в MSDN.

А на сайте OWASP есть обзор поддержки HttpOnly в различных браузерах. Если кратко, то на текущий момент это IE 6+, FF 2.0.0.6+ (с багом) и Opera 9.50+. В Webkit только планируется.

На серверной стороне HttpOnly изначально поддерживается в .NET 3.0+, PHP 5.2+, Ruby on Rails, Java Servlets 3.0+ и Jetty, однако даже если используемый вами сервер эту функцию не поддерживает, не составляет хоть сколько-нибудь большого труда реализовать её самому.

И помните, что передавать идентификатор сессии в URL крайне небезопасно, т.к. помимо уязвимости к XSS ваш сайт может быть атакован с помощью session fixation.

Давайте сделаем интернет более безопасным, включив в своих приложениях HttpOnly.
Спасибо за внимание.

Opera 9.51: 4242.80ms (Total)

Firefox 2.0.0.16: 12199.00ms (Total)

Firefor 3.0.1: 3268.80ms (Total)

Konqueror 3.5.9: 47187.60ms (Total)

Arora 0.3: 35139.40ms (Total)

Сравнение