суббота, 4 декабря 2010 г.

[life.sport.darts] Несколько слов о Unicorn-овских дротиках Andy Hamilton 97% 23g

С месяц назад соблазнился изрядной скидкой на Unicorn-овские дротики Энди Хамильтона из серии Maestro Latinum (97% содержание вольфрама, 23 грамма вес) – на dartscorner.co.uk они стоили всего 22.33GBP. Для дротиков с таким высоким содержанием вольфрама (а больше 97% я никогда не видел) это совсем не высокая цена. В общем, желание иметь понтовые дротики, которые были бы тоньше, чем мои Target Aviator, в сочетании с большой скидкой сделали свое черное дело – я решился на покупку.

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

пятница, 3 декабря 2010 г.

[prog] OTL4, MSSQL, bulk insert, триггер на вставку и ошибка 24000

Нужно было сделать быструю вставку записей в табличку MSSQL. Задействовал нестандартную SQL-ную фичу с конструкцией insert into … select … union all … select … union all. Работал через OTL4 и сделал пул otl_nocommit_stream-ом (с разным количеством строк внутри). Например, если в пуле были otl-потоки для 20, 10, 5, 2 и 1-ой строки, а нужно было вставить 59 строк, то два раза использовался поток на 20 записей, один раз поток для 10 строк, один раз поток для 5 строк и два раза поток для 2-х строк.

Все работало хорошо до тех пор, пока в базе не появился триггер на вставку в эту таблицу. Триггер должен был срабатывать на insert и добавлять строки в другую таблицу. Но после того, как он срабатывал, у меня при выборе следующего otl-потока из пула возникала ошибка 24000: [Microsoft][SQL Server Native Client 10.0]Invalid cursor state.

Поиск по Интернету показал, что такие вещи при работе через ODBC уже случались. И в качестве workaround-а рекомендовали после каждого SQLExecute для вставки в основную таблицу делать обращение к SQLMoreResults.

Легко это сделать когда ты сам осуществляешь вызовы SQLExecute. Но за меня это делает OTL. Да еще делает это неявно для меня, внутри своих otl-потоков. Так что как применить данную рекомендацию поначалу было непонятно.

К счастью, OTL доступен в исходных текстах (более того, весь OTL – это один большой заголовочный файл). Посредством поиска удалось выяснить, что обращение к SQLMoreResults в OTL есть. Происходит оно внутри метода sql_row_count(), а sql_row_count() вызывается после обращения к SQLExecute.

Но sql_row_count() использует SQLMoreResults не всегда, а только когда определен макрос OTL_ODBC_ALTERNATE_RPC. И в документации к OTL_ODBC_ALTERNATE_RPC сказано, что он предназначен для PostgreSQL:

This #define should be used with the PostgreSQL ODBC driver. The driver returns as many row counts via SQLRowCount() calls as there are rows in a batch INSERT statement. The #define enables a loop that fetches all individual row counts and sums them up (+=). As a result, otl_stream::get_rpc() returns the total, which is correct for PostgreSQL. Normally, commercially available ODBC drivers return a single row count on a batch INSERT.

Тем не менее, определил макрос OTL_ODBC_ALTERNATE_RPC и все заработало!

Мораль сей басни – доступные исходники сторонних библиотек – это must have. :)

[life;work] Мерзнем-с. Посему тянет на воспоминания и философствование.

Второй день на работе холодно – в здании, где мы арендуем помещения, что-то случилось с системой отопления и батареи едва теплые. Хорошо хоть, что сегодня всего около –8 за окном, вчера было в два раза холоднее. Хорошо хоть, что есть кондиционеры (вряд ли они рассчитаны такие условия, но пока работают).

Вспоминается год 1997-й или 1998-й, когда я в КБСП работал. У КБ тогда в распоряжении было три здания: двухэтажная бывшая столовая, трехэтажное длинное здание (ВМК, если память не изменяет), в котором когда-то размешался Эльбрус и машинные залы, а так же современная высотка из стекла и бетона (которая в кулуарах называлась “стилобат”).

Поскольку денег тогда у КБСП на нормальное отопление не было, то практиковалась следующая схема – летом народ размещался в стилобате, а на зиму переезжал в ВМК. Поскольку ВМК на такое скопление народа не было рассчитано, то в большие комнаты заселяли сразу по два отдела. Так, зиму с 1994-го на 1995-й наш отдел (8 человек)  делил комнату в 16-17 квадратов с отделом электронщиков (4 человека). Правда, на следующую зиму этого отдела в КБ уже не осталось, и всю комнату отдали в наше полное распоряжение.

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

Разницу в качестве строительства старой ВМК, возведенной в начале 70-х из кирпича, и более-менее новой панельной столовой мы почувствовали с наступлением первых холодов. Но еще лучше это стало заметно когда внезапно ударили морозы под 25 градусов.

Это была песТня :( При теплых батареях и работающих обогревателях у нас в комнате температура не поднималась выше 13 градусов тепла. Работали сидя в зимней обуви и зимней верхней одежде. Особенно везло тем, у кого были тонкие вязанные перчатки – можно было работать на клавиатуре не снимая их. А без перчаток руки минут через 20-30 просто отмерзали.

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

Однако ж… Вот тогда было хреново, да и деньги платили смешные. А тем не менее, в КБСП у нас был очень сплоченный коллектив. Ушел только один человек и то вынуждено. Мы же верили, что занимаемся очень перспективным продуктом. И что если выдержим, то все наши труды окупятся… В какой-то степени так и вышло. Не в КБСП, правда, а в Интервэйле, где нам удалось сильно развить обсуждавшиеся в КБ идеи.

Так что вспоминая, как мы тогда мерзли, у меня сейчас нет чувства бесполезно потраченного времени. И решение никуда не срываться, а остаться в КБСП я до сих пор считаю правильным. Но вот сильно сомневаюсь, что если бы сейчас обстоятельства заставили бы вернуться в такие же спартанские условия, стиснуть зубы и потерпеть несколько лет с верой в то, что мы затем всех порвем…

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

четверг, 2 декабря 2010 г.

[life.sport.darts] Австралийский интернет-магазин с полезной особенностью

Во многих магазинах наблюдается один и тот же недостаток: если у какой-то модели дротиков есть несколько вариантов веса (скажем, 20, 22, 24 и 26 грамм), то в качестве изображения дротиков приводится фотография только одной модели. Ну вот, например, на dartscorner.co.uk модели Unicorn Sigma Pro 970 веса 21 грамм и 27 грамм. Чем различаются их изображения?

Да что там магазины. Сам производитель дротиков Unicorn на своем сайте приводит только одно изображение для своей серии Sigma Pro 970!

Между тем, если внимательно посмотреть спецификации дротиков разного веса, то можно увидеть, что они имеют и разную длину, и разную толщину. Неужели вне зависимости от различия в размерах они выглядят одинаково?

Отнюдь. И это очень хорошо видно в австралийском интернет-магазине DeadEye Darts, в котором имеется отдельная фотография на каждый вариант одних и тех же дротиков. Вот, например, легко можно увидеть, как различаются между собой Sigma Pro 970 разных весов:

21 грамм:

27 грамм:

Вот такое полезное и редкое качество. Которое, однако, не означает, что следует заказывать дротики в Австралии :)

среда, 1 декабря 2010 г.

[work;prog] О парочке демотиваторов

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

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


Фактор первый. Как легко рассказать (написать) о том, что тебе кажется нужным на будущий год – нанять N человек, закупить K серверов, докупить того-то и того-то – если можно это сделать в свободной форме. И как же все это усложняется, если нужно заполнить пару сверстанных кем-то Excel-евских табличек для той же самой информации!

Блин, даже не верится, насколько сложно. Второй день смотрю в монитор, туплю, матерюсь про себя, а воз и ныне там. Имхо, похожая ситуация происходит, когда нужно заполнить анкету в какой-нибудь государственной организации (в налоговой, например) – вроде бы все просто, все графы более-менее понятны, а даже с образцом перед глазами получается все заполнить только со второй (третьей,…) попытки и под чьим-нибудь чутким руководством :(

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

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


Фактор второй. Оценка успешности работы сотрудника по сколько-то-там-бальной шкале. Т.е. предложение вида “оцените вклад каждого сотрудника за истекший год по следующей шкале: A – …, B – …, C – …” уже приводит меня в замешательство, граничащее с приступом бешенства. А дополнение “оценку A можно выставить не более 10% сотрудников, …” вообще повергает в полный ступор (что, к счастью, оберегает от взрыва бешенства).

Почему так происходит?

Во-первых, сложно проводить какие-то границы по живым людям. Вот этот человек получает оценку A, а вот этот B, поскольку оценки A- или B+ просто нет. Да еще и нельзя две оценки A поставить.

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

Гораздо проще было бы, если по итогам года мне говорят: “Твоя команда заслужила премию в размере M тугриков. Твоя задача – разделить ее между своими людьми в зависимости от их вклада.” Вот это уже совсем другое дело: живые деньги делить – это не оценки расставлять :)

Фактически, тема оценок труда программиста чем-то отличным от живых денег может считаться продолжением “KPI для программистов” (№раз и №два).

[prog] Описание нововведений Scala 2.8: The Scala 2.8 Actors API

Продолжается серия статей с описанием новых возможностей Scala 2.8. На этот раз статья описывает Scala Actors (которые появились в Scala раньше, но в версии 2.8, afaik, претерпели некоторые изменения): The Scala 2.8 Actors API.

Ранее были опубликованы статьи: