пятница, 20 августа 2010 г.

[life.flame] Блин, за державу обидно!

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

Кстати есть тема про которую я давеча говорил применительно к украшке - т.к. белорашка отстает от рашки в развитии лет на 5-7, то любой Господин Компьютерщик™ прозябающий последние пару лет в Москве может уехать туда и открыть контору про какому-нибудь офшорному программированию.
На фоне местных спецов любой Сисадмин Коксов будет светочем и прометеем.
Денег в абсолютных цифрах немного, но в относительном плане соотношение поднимаемого бабла к получаемому за него уровню жизни будет сплошной выигрыш.

Сисадмины, сисопы, эникейщики стройййсь! Ровными рядами в Белоруссию шаааагом аарш!

Блин, абыдно за державу-то! :) Я, конечно, не знаю общей температуры по больнице общего уровня отечественных разработчиков/админов, но примеров, когда какой-нибудь слинявший из Москвы Сисадмин Коксов организовывал в Беларуси успешную офшорную контору у меня перед глазами нет. Тогда как за обратными примерами (хорошо устроившимися в Москве белорусскими разработчиками, сисадминами и предпринимателями) ходить далеко не нужно.

PS. Прошу воспринимать данную тему с большой долей юмора – не могу иной раз удержаться от подколки столичных снобов ;)

PPS. Кстати, есть у меня предположение, что 90% ЖЖ-ников, запрещающих оставлять комменты по openID (т.е. разрешающих комментарии только от ЖЖ-ников), имеют секс с мужчинами.

четверг, 19 августа 2010 г.

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

Разработчики языка Scala планируют опубликовать серию описаний возможностей Scala 2.8. Начали они с описания новых коллекций/контейнеров.

Прочитать на английском можно здесь: The Scala 2.8 Collections API.

[prog.thoughts] О предсказании сроков написания программ

В программировании есть несколько очень сложных проблем, не имеющих однозначного решения. Как то: определение настоящих желаний заказчика; выбор хороших имен для идентификаторов; предсказание сроков реализации; объяснение подчиненному того, что ты от него хочешь получить (см.первый пункт списка)… Сегодня выдаю поток сознания на тему того, почему лично я никогда не угадываю со сроками написания программ.

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

Это вопрос веры еще и потому, что невозможно представить себе точный объем предстоящей работы. Во-первых, есть семантический разрыв. На эту тему я уже писал почти год назад. Но влияние этого разрыва на точность сроков чрезвычайно велико – объем фактической работы отличается от объема предполагаемой работы в разы.

Во-вторых, далеко не всегда есть вообще четкие идеи о том, что и как будет делаться. Вот, например, я недавно обнаружил, что правила маршрутизации сообщений в нашем шлюзе достигли предела нормального восприятия. Стало понятно, что их нужно упрощать и приводить к какому-то другому виду. Но к какому? Идей нет, их еще предстоит выносить и родить. Сколько на это потребуется времени? Без понятия. Может быть день, может быть неделя, может быть месяц. Я могу исходить только из собственной самоуверенности – когда-то мне потребовалось около месяца на рождения некоего алгоритма. По сложности задачи кажутся мне равнозначными. Поэтому я верю в то, что месяц на проектирование новой формы правил маршрутизации – это реально. Но это только вера, она не подкреплена никакими выкладками.

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

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

  • рабочих дней в неделе всего пять. Т.е. месяц – это не 30 дней, а около 20 рабочих. Почему-то я упорно не могу заставить себя разделять выходные и рабочие дни, наверное, большой опыт авральных проектов сказывается :(
  • на определенных стадиях проектов эффективное рабочее время будет составлять всего 2-3, в лучшем случае 4 часа в день. Т.е., если для проектирования решения потребуется 16 часов, то это не два рабочих дня, а 5-8 рабочих дней;
  • расходы времени на коммуникации с коллегами. Между тем, расходы собственного рабочего времени при этом растут просто катастрофически. Например, если ко мне обращается подчиненный с вопросом на 20 минут обсуждения, то чтобы вернуться к работе мне требуется, как минимум, раза в два больше времени. Следует добавить сюда и огромный расход энергии на то, чтобы быстро включиться в тему нового разговора;
  • непредвиденные технические проблемы. Начиная тем, что ты сам неверно прочитал документацию и написал код в ошибочных предположениях, заканчивая глюками или недокументированными особенностями сторонних библиотек. Из этой же оперы и ошибки в технических предположениях: например, почему-то предполагалось, что асинхронный I/O в конкретных условиях будет выгодным, а на деле вышло наоборот;
  • разнообразные личные обстоятельства и житейские форс-мажоры – сам заболел или с ребенком нужно посидеть, или за какими-нибудь справками нужно бегать в рабочее время;
  • элементарное отсутствие желания работать. Да, если задача захватила тебя полностью и ты желаешь ее натянуть по самые гланды – тогда душа поет и руки сами код пишут. А если нет? Чем старше становишься, чем больше сделанного за плечами, тем меньше адреналина от новых задач. Посему из 8-ми часов рабочего времени (минус все вышесказанное) изрядный процент времени будет уходить на то, чтобы побороть свое эротическое к ней отношение. Кстати, все офисные time killer-ы вроде блогов, форумов, YouTube и пр. попадают в эту категорию. За исключением дартса и турника – это совсем другое дело.

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

Причем, когда я называю свой срок, я уже произвожу такое умножение (на коэффициент в диапазоне от 2 до 4-х), но все равно ошибаюсь. А взять больший коэффициент не позволяет (пока?) все тоже самомнение: “Ну как же! Да не может быть, чтобы вместо одной недели потребовалось пять-шесть недель!” :)

[life.humour] Мороженное в форме пистолета и старый анекдот

Наткнулся в Интернете на фотографии дегустации мороженного в форме пистолета:

и вспомнил старый анекдот:

Учительница в школе спрашивает у детей:
-- Машенька, ты кем хочешь быть, когда вырастешь?
-- Продавцом.
-- Молодец! А ты, Ванечка?
-- А я – водителем!
-- Хорошо, ну а ты Вовочка?
-- А я сексопатологом буду!
-- ???!!! А кто это?
-- Это доктор.
-- А кого он лечит?
-- Вот смотрите, Марья Ивановна, по улице идут три женщины с мороженным. Одна его лижет, вторая сосет, а третья кусает. Какая из них замужем?
-- Ну… э… ну… может быть та, которая кусает?
-- Замужем та, у которой обручальное кольцо. А вот таких как вы я и буду лечить!

Так кто же из изображенных на фотографиях дам замужем? ;)))

[prog] Вышел Ruby 1.9.2!

Анонсирован выход новой версии языка Ruby – 1.9.2. Официальный список изменений я приведу, хотя мне он мало что говорит (за исключением, разве что, пункта про $:):

  • Множество новых методов.
  • Новый API для сокетов (с поддержкой IPv6).
  • Поддержка новых кодировок.
  • Класс Random, который поддерживает разные типы генераторов случайных чисел.
  • Класс Time переделан, теперь нет проблемы 2038 года.
  • Некоторые улучшения в регулярных выражениях.
  • Глобальная переменная $: теперь не содержит текущего каталога.
  • Пакет dl теперь реализован на основе libffi.
  • Новая библиотека psych, которая является оберткой над libyaml. Может использоваться вместо syck.

Более подробные списки изменений в NEWS.

Бинарных сборок под Windows на ruby-lang.org пока нет :( Так что про совместимость моих проектов с Ruby 1.9.2 ничего еще сказать не могу.

среда, 18 августа 2010 г.

[prog] Вторая часть интервью Александреску на informit.com

На informit.com опубликована вторая часть интервью Андрея Александреску о языке D (ссылку на первую часть так же можно найти у меня в блоге).

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

[life.sport.darts] Чтобы перышки с хвостиков не слетали

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

Есть пластиковые/нейлоновые хвостики с металлическими колечками (например, таковыми являются Unicorn Gripper). В них колечко сжимает кончики хвостика, чтобы те лучше держали перышки. Выглядит это, приблизительно, так:

unicorn shaft and flight

Т.е. колечко располагается под перышком.

Такие хвостики держат перышки лучше. Но это если Unicorn-овские хвостики (там пластик жесткий). А вот если это нейлоновые хвостики от Red Dragon Darts, то не очень – кончики более длинные и мягкие, поэтому колечко не так эффективно.

Однако все равно, Unicorn-овские это хвостики с колечком или нет, но перышки выскакивают регулярно. У меня, наверное, один раз в 3-5 минут на тренировке это происходит. Иногда бывает так, что бросаешь три дротика подряд, и из каждого перышки вылетают :(

Пару дней назад роясь в Интернет-магазине Red Dragon Darts обнаружил интересную штуку с непонятным, по началу, назначением – Flights Puncher:

flights puncher

Хорошо, там была ссылка на YouTube-овский ролик с демонстрацией этого puncher-а:

Я решил попробовать. Puncher-а, понятное дело, у меня нет, так что обошелся обычным строительным ножом. Результат не такой симпатичный, но настолько же эффективный:

my punched flights

Держатся очень крепко. Вчера за час тренировки ни разу ни одно перышко не вылетело. Был приятно поражен.

Как я понимаю, Red Dragon-овские нейлоновые хвостики специально под такой механизм крепления сделаны – поэтому у них и кончики подлиннее, чем у Unicorn-а, и материал не жесткий, а упругий. А с Unicorn-ом так может и не получиться. Ну да это уже не мои проблемы, у меня Red Dragon ;)

Вот такое неожиданное и приятное открытие. Правда, один недостаток уже обнаружился – для перевозки оснащенных такими хвостиками и перышками дротиков нужен специальный футляр, в котором их можно хранить, не снимая оперения.

вторник, 17 августа 2010 г.

[life] Фотографические ролики: завораживающие зрелища

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

Hayaku: A Time Lapse Journey Through Japan from Brad Kremer on Vimeo.

ММК изнутри

The Sandpit from Sam O'Hare on Vimeo.

Ссылки найдены в Тупичке Гоблина.

[prog] Не могу не выдернуть фразу из интервью Алана Кея

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

Компания, в которой я работаю уже больше девяти лет, начиналась и до недавнего времени развивалась как стартап – много вкалываем, за многое отвечаем, зато есть свобода и отсутствие формализма. Мы были, как мне казалось, developer-oriented company (см. мой вчерашний пост). Теперь в компании начинают вводить корпоративную культуру, жесткое планирование, отчетность и показатели эффективности. Как мне кажется, мы становимся profit-oriented company. Что ведет к грустным мыслям вроде “Какого х*я я все это время занимался узкоспециализированными задачами и куда с таким багажом деваться?”

И вот читая свежее интервью Алана Кея я натыкаюсь на фразу:

One part of a “revival” could be done by simply adding back a category of funding and process that was used by ARPA-IPTO in the 60s (and other great funders such as the Office of Naval Research). Basically, “fund people, not projects”, “milestones, rather than deadlines”, “visions rather than goals”. The “people not projects” part meant “super top people”, and this limited the number who could be funded (and hence also kept the funding budget relatively low).

что в моем вольном переводе звучит как:

Одна часть “возрождения” [eao197 – речь шла о возвращении инновационных институтов] могла бы быть простым возвратом к такому финансированию и организации процессов, которые использовались в ARPA-IPTO в 60-х (и у других замечательных инвесторов, вроде Управления военно-морских исследований). По существу: “инвестируй в людей, не в проекты”, “вехи (достижения), а не сроки”, “представления (идеи), а не цели”. Конкретно “люди, а не проекты” означает “самые лучшие люди”, что серьезно ограничивает число тех, кого можно спонсировать (что, в свою очередь, оставляет инвестиционный бюджет относительно низким).

Да, Алан Кей говорил про исследовательские лаборатории. Это не поточное производство ПО, понятное дело. Но я, похоже, с трудом вписываюсь в поточное производство. Если вообще вписываюсь :(

понедельник, 16 августа 2010 г.

[prog] Большой монолог Charles Nutter о наезде Oracle на Google

My Thoughts on Oracle v Google – очень много слов на английском о том, почему Oracle наехал на Google, в чем суть упомянутых Oracle патентов и чем все это может закончится по мнению самого Чарлза Наттера. Слов очень много, но читать интересно.

Кстати, Чарлз Наттер – это один из ведущих разработчиков JRuby.

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

Потом дела JavaME пошли плохо, т.к. Sun начала вкладываться исключительно в JavaEE, а про JavaME забыла. Что не устраивало производителей мобильных телефонов. Когда же Google решила поучаствовать в дележе быстрорастущего рынка мобильных устройств (уже далеко не только телефонов), она решила создать свою, полностью открытую платформу. Но, поскольку лицензировать Java – это очень непросто (и, надо полагать, недешево), то Google пошел по совсем другому пути.

В Google разработали Dalvik – свою систему исполнения Java программ. Фокус в том, что Dalvik – это не JVM, не виртуальная машина Java. Dalvik даже не понимает Java-байткода, для Dalvik нужно перекомпилировать Java-приложение в другой набор инструкций. Так же, Google не поддерживает полностью все классы из JDK, а только значительную их часть, но не всю.

Т.е., Google сделал для Android-а свою Java, которая, формально говоря, вовсе не Java, поскольку сертификацию она не проходила. Но производителей мобильных устройств это не колышит. Android отличная бесплатная платформа для их нужд, куда лучше JavaME, и разработчики Android-ом очень довольны, не желая больше связываться с JavaME. Так нафига козе баян какой-то там логотип о совместимости? ;)

Но, раз Android – это не 100% Java, то никто уже Oracle за лицензирование Java платить не будет. Т.е. Oracle потеряет даже те небольшие деньги, которые приносили Sun-у лицензии на JavaME. Отсюда и наезд на Google, ведь Oracle не любит терять деньги. Отличная фраза была высказана на этот счет:

…But Oracle's not a developer-oriented company (like Sun)...it's a profit-oriented company (unlike Sun, sadly),…

В общем, прочитал с удовольствием, хотя букв ну уж очень много :)

А главный вывод, который я для себя сделал: патенты на ПО – must die!

воскресенье, 15 августа 2010 г.

[life.photo] Серия фотографий In silhouette

Сегодня в рубрике “Знакомство с фотомастером” не будет знакомства с каким-то одним фотографом. Вместо этого будет ссылка на очень понравившуюся мне подборку из 37 снимков под названием In silhouette.

Под катом несколько самых-самых снимков (на мой деревенский вкус, разумеется).