Размышлизмы eao197: 24 января 2010 г.

суббота, 30 января 2010 г.

[work] Бывает ли уверенное знание PL/SQL и общее знание БД Oracle?

На RSDN проскочила ссылка на вакансию в Банке Тинькофф.

Возможно, в требовании “Уверенное знание языков и библиотек С++, С#, Java” запятая означает “ИЛИ”. Т.е. уверенное знание языков и библиотек C++ ИЛИ C# ИЛИ Java – в такой формулировке все нормально.

Но вот это несколько меня смущает:

Уверенное знание SQL и PL/SQL.
Общие знания БД Oracle.

PL/SQL, насколько мне известно, является исключительно Oracle-вой штучкой. Поэтому уверенное знание PL/SQL, имхо, возможно только после очень плотной работы с БД Oracle. И сочетание “уверенного знания PL/SQL” и “общего знания БД Oracle” выглядит, по меньшей мере, странно.

Или же здесь под “знанием БД Oracle” понимается опыт администрирования БД? Но и тогда странно – не дело разработчика администрировать серьезную БД, а администратору большой БД – программировать на C++.

Почему меня это так заинтересовало? Поскольку доходили до меня слухи, что этот банк один из самых продвинутых (в смысле иноваций) в России. А тут такая странная вакансия.

[work] Создал себе профиль на LinkedIn. Зачем-то…

Собственно, вот: http://www.linkedin.com/in/eao197

Чё с ним делать – хз, ну раз появился, то пусть будет :)

[life] Мать Тереза: жизнь, это…

Недавно прочитал, сильно задумался…

ЖИЗНЬ, это возможность — используйте её.
ЖИЗНЬ, это красота — восхищайтесь ею.
ЖИЗНЬ, это блаженство — вкусите его.
ЖИЗНЬ, это мечта — осуществите её.
ЖИЗНЬ, это вызов — примите его.
ЖИЗНЬ, это долг — исполните его.
ЖИЗНЬ, это игра — сыграйте в неё.
ЖИЗНЬ, это богатство — дорожите им.
ЖИЗНЬ, это любовь — наслаждайтесь ею.
ЖИЗНЬ, это тайна — познайте её.
ЖИЗНЬ, это шанс — воспользуйтесь им.
ЖИЗНЬ, это горе — превозмогите его.
ЖИЗНЬ, это борьба — выдержите её.
ЖИЗНЬ, это приключение — решитесь на него.
ЖИЗНЬ, это трагедия — преодолейте её.
ЖИЗНЬ, это счастье — сотворите его.
ЖИЗНЬ, слишком прекрасна — не губите её.
ЖИЗНЬ, это жизнь — боритесь за неё.

пятница, 29 января 2010 г.

[life.photo.wow] Сюрреалистичный снимок прыгающей через костер лошади

Фотография с ежегодного фестиваля в честь Святого Энтони, в испанском городке Сан Бартоломью де Пинарес (San Bartolome de Pinares):

На этом фестивале всадники со своими лошадьми прыгают через костер:

Снимки найдены здесь: Fiery European Festivals. Там же есть интересные снимки с фестиваля викингов:

[life.business] Еще интересное на тему “Своя компания”

В продолжение моих предыдущих заметок (первая, вторая) интересная статейка на Хабре: Четыре облома собственного бизнеса:

Вот так. Избавляйтесь от иллюзий. Залог успеха – реалистичный взгляд на стоящую проблему. Меньше разочарований – больше сил для новых свершений. И если не витать в розовых мечтах вначале, то они вполне могут стать явью потом.

Да, и ещё. Если вы высоко цените себя как специалиста, бойтесь своего бизнеса! Лучше быть фрилансером и профессионально расти, чем погонщиком двадцати ленивых наёмников и профессионально деградировать.

(найдено через BELNETMON)

[life.cinema] Очередной кинообзор

Пришло время очередного кинообзора :)

Змий. Отличный французкий триллер. Мне понравился. Кстати, исполнитель главной роли играл так же в классном фильме “Неуловимый” с Софи Марсо. Если кто-то не смотрел эти фильмы, то рекомендую.

Пророк. По сравнению с очень многими фильмами 2009-го, о которых забываешь сразу после просмотра, это сильный фильм. И снят в необычной манере. Стоит посмотреть.

Рука на счастье. Простенький, бюджетный, но местами смешной. Потраченого времени на него было не жалко.

Белая мгла. Кейт Бекинсейл, конечно, красивая женщина и смотреть на нее приятно, но фильм это не спасает. В происходящее на экране не веришь ни сколько. Так что фильм – полная мура.

Дориан Грей. Необычно снят, своеобразная стилизация под старину. По мне, так фильм средненький, а жене понравился.

Безумный спецназ. Не понял этого фильма. Какой-то настолько тонкий стеб над чем-то, что я его не улавливал, особенно в конце картины.

Козырные тузы 2. По сравнению с первым фильмом – почти полная лажа. И по вменяемости сюжета, и по динамизму, и по исполнению – по всем параметрам фильм уступает предшественнику. Так что можно и не смотреть.

Жизнь Дэвида Гейла. Хорошие актеры, хорошо играют. Но для меня фильм оказался "немного предсказуем" – где-то с середины фильма я понял, чем он закончится.

Чудо. Хорошо сыграл Сергей Маковецкий. Да и вообще снятно нормально. Но вообще все происходящее воспринимается как байка. Типа хотите верьте, хотите нет. А вот впечатления, что все это снято по реальным событиям у меня не возникло.

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

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

Шерлок Шолмс. Добротно сделанная фантастическо-детективная сказочка-боевик. В которой главными героями почему-то оказались Шерлок Холмс и доктор Уотсон, а не какой-нибудь Ван Хельсинг. Никаких сравнений с нашими старыми фильмами про Холмса даже не возникает, поэтому картину можно смотреть спокойно и с удовольствием. Данная работа не самая сильная у Гая Ричи (“Карты, деньги и два ствола” и “Рок-н-рольщик” покруче будут), но на вполне среднем уровне.

Книга Илая. Старательно сделанный, но банальный и растянутый постапокалиптичный боевичок, с супер-пупер-крутым главным героем. Частично все это компенсируется интересным сюжетным поворотом в конце. В результате мне вроде и не жалко потраченного на просмотр времени, но и рекомендовать его я не буду.

Черная молния. Красочно сделанная сказочка для детей младшего школьного возраста.

Дорога. Я думал, что это будет очередной постапокалиптический боевичок в духе "Книги Илая". Но оказалось, что это суровая драма, снятая в мрачной постапокалиптичной атмосфере. Картина сделана очень добротно, отлично играет Вигго Мортенсен. Так что любителям такого жанра может понравится. Мое же впечатление: скучная тягомотина.

четверг, 28 января 2010 г.

[comp.prog] Фронт-энд для Go будет включен в GCC

Новость о языке Go из списка рассылки GCC:

I am pleased to announce that the GCC Steering Committee has
accepted the contribution of the gccgo front-end and gcc-specific runtime
for the Go language with Ian Taylor appointed maintainer. The GCC
Release Managers will decide the details about the timing of the merge and
inclusion in GCC 4.5 or later.

Интересно. Так ведь не успеешь оглянуться, а Go уже мейнстримом станет. Что, наверное, не так уж и плохо.

[comp.wow] Apple iPad

Поскольку я представляю здесь время от времени разные мобильный штучки, то не могу не поделиться вот этой ссылкой: Live from the Apple 'latest creation' event. Планшет от Apple, о котором так долго ходили слухи, таки был представлен общественности!

Интересно, когда он доберется до СНГ-овии и сколько он здесь будет стоить?

[comp.prog.humour] Объектно-ориентированная – это понятно, но на что именно она ориентированная?

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

По окончании первого года обучения (осень 1997) всех аспирантов математического факультета собрали на совет факультета чтобы отчитаться о проделанной за год работе. Когда дошла очередь до меня я рассказал, что разработал прототип объектно-ориентированной СУБД и опробовал его в проекте, который наша кафедра вела совместно с одним из заводов. Вопросов ко мне не было, поскольку мало кто из присутствующих вообще имел представление об объектных БД. Тогда в дело вступил зав.кафедрой “Математических проблем управления”, проф. Максимей Иван Васильевич, и у нас состоялся такой диалог:

-- Так ты занимался базой данных?
-- Да, объектно-ориентированной базой данных.
-- Ну, то что она объектно-ориентированная – это понятно, но на что конкретно она ориентирована?

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

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

среда, 27 января 2010 г.

[comp.prog] Анонсирована первая бета-версия Scala 2.8.0

Вот полный текст анонса: Scala 2.8.0 Beta 1.

Из того, что было переделано и добавлено (моя выжимка из общего списка):

переработанная библиотека коллекций (вроде бы с хорошей обратной совместимостью). Подробности здесь: http://www.scala-lang.org/sid/3
новая реализация массивов, манифесты для полиморфных массивов. Подробности здесь: http://www.scala-lang.org/sid/7
специализация типов. Вроде бы позволяет указывать специализации для обобщенных функций, по которым компилятор будет сам генерить несколько реализаций и использовать наиболее подходящую из них в месте вызова. Подробности здесь: http://www.scala-lang.org/sid/9
именованные аргументы и аргументы по умолчанию. Подробности здесь: http://www.scala-lang.org/sid/1
пакеты как объекты. eao197: насколько я понял, пакеты сейчас становятся чем-то вроде объектов и могут иметь собственные методы, поля и определения типов. Эта функциональность пока не завершена и полностью станет доступной позже.
переработанный REPL. Теперь поддерживается автодополнение по табуляции для всех пакетов, которые находятся в classpath и пр. улучшения.
улучшенная библиотека Actors. Новые Reactor-ы, актеры смогут использовать fork/join возможности из JSR166y (что дает прирост производительности на JVM 1.6), диспетчеры теперь могут добавляться и адаптироваться под собственные нужды как плагины.

Плюс улучшения в компиляторе (вплоть до увеличения скорости работы на 50%).

Плюс новые инструменты: Scaladoc 2, Sbaz 2, Scalap, Scala IDE for Eclipse.

Ну что тут скажешь… Scala продолжает активно развиваться. Учитывая количество багов, которые они вносят в каждом новом релизе, стабилизируется ветка 2.8.0 не раньше чем месяцев через 5-6. А там, глядишь, уже какой-нибудь Scala 2.9 на подходе будет. Пока все идет по сценарию языка D :( С другой стороны, пока пользователей у языка не очень много, еще можно экспериментировать и доводить язык до ума. Опять же, я на Scala не пишу, меня это не затрагивает, так что пускай экспериментируют :)

[comp.prog.humour] Маразм крепчал: объектно-ориентированные аргументы командной строки

Вот такое вот новшество в MPlayerXP 0.7.95:

Renamed command-line arguments to be more object-oriented

Т.е. аргументы командной строки были переименованы чтобы быть более объектно-ориентированными. Это пять!

PS. Новость найдена на LOR-е.

[comp.prog] Свежее интервью Matz-а в InfoQ

Мне, как бывшему Ruby-исту, было интересно прочитать свежее интервью Якихиро Мацумото (Matz), создателя языка Ruby, в журнале InfoQ.

Если его коротко пересказать, то получается следующее:

в последнее время Matz активно работал над веткой 1.9 языка Ruby, которая гораздо быстрее, чем 1.8. Так же в Ruby пытаются сделать поддержку нескольких виртуальных машин Ruby в рамках одного процесса;
когда Matz начинал разработку Ruby, он имел представление о функциональном программировании в рамках возможностей языка Lisp. И лишь затем познакомился с более продвинутыми средствами, которые доступны в Haskell и OCaml, хотя понимание некоторых из них дается ему с трудом;
если бы Matz разрабатывал Ruby с нуля сейчас, он бы попробовал добавить в Ruby что-нибудь из функциональных языков. Например, какую-то форму ленивых вычислений. Но вот добавление этих возможностей в уже существующий язык представляется очень тяжелым делом – слишком многое придется менять в дизайне языка;
по мнению Matz попытки “подружить” функциональный и объектно-ориентированный подходы в одном языке (вроде того, что делают в Scala) – это очень трудное дело, в котором обязательно чем-то придется жертвовать;
Matz знаком с Haskell, написал несколько маленьких программок и его впечатление о типах и о самом Haskell-е неоднозначное. По поводу типов – с одной стороны, они помогают вылавливать ошибки на ранних стадиях, но с другой – это лишняя головная боль для разработчика, поскольку о них постоянно нужно думать. И даже автоматический вывод типов и компактность языка здесь не сильно помогают, т.к. типы все равно никуда не исчезают и о них нужно думать. Так же в Haskell-е программисту хорошо тем, что он описывает, что он хочет сделать, а не как это делать. Но при этом сам Matz не всегда понимает, как же именно будет работать программа. В языке Ruby с этим проще – его вычислительная модель тривиальнее;
язык Clojure и использование STM кажется Matz-у интересным. Хотя он и не считает, что Clojure является чем-то новым. Скорее хорошо упакованным набором давно известных вещей. А вот внедрение STM в Ruby выглядит маловероятным, поскольку язык изначально не был предназначен для этого;
Matz считает, что Ruby похож на SmallTalk, но является более легковесным. На Ruby проще писать маленькие программки, которые не тянут с собой большие image-файлы. Поэтому Ruby является более практичным языком;
Matz радует наличие портов Ruby для других платформ – JRuby и Iron Ruby. За Iron Ruby он не следит, а вот JRuby ему кажется очень интересным. А то, что программы, написанные специально для JRuby не будут работать на Ruby MRI он не считает проблемой – да, есть такая особенность. Это в точности тоже самое, что и Ruby-программы, заточенные только под Unix или только под Windows;
что касается дизайна языка, то если нужно было делать выбор между удобством языка и скоростью, Matz делал выбор в пользу удобства. Поэтому Ruby MRI не быстр. Но ребята из команды проекта Rubinius напряженно работают, чтобы создать быструю реализацию. Так же Matz сильно озабочен тем, чтобы язык не оказался переусложненным. Чтобы не оказалось как в C++, куда была добавлена относительно не сложная штука – шаблоны, но из-за которой сложность языка C++ слишком увеличилась;
сильно Matz уважает разработчиков языка Python. По его мнению в Python сложился и очень хорошие библиотеки, и хороший дизайн самого языка. И вообще, сейчас выбор динамического языка – это вопрос вкуса. Кому-то нравиться Python, кому-то Ruby. Это точно так же, как кто-то любит собак, а кто-то – кошек.

Еще Matz высказался в том плане, что сейчас доминирующей парадигмой является ООП, которая появилась очень давно – в 50-60 годах. И что в ближайшие несколько десятилетий мы вряд ли увидим какую-то другую настолько же мощную парадигму за исключением функционального программирования (которое само по себе так же далеко не ново).

Много Matz говорил о поддержке конкурентного программирования. С упором на модель актеров. По его мнению, лучший подход к этой проблеме – это сосредоточение всех модификаций состояния внутри агентов и взаимодействие агентов между собой посредством сообщений. И что эта штука в языке будет перспективнее, чем STM. Хотя он не знает, будут ли актеры частью языка или же просто Ruby-овой библиотекой (коих для Ruby существует уже пара-тройка штук).

eao197: ёптыть, очень приятно осознавать, что коллектив, в котором мне повезло работать в конце 90-х, додумался до этого уже тогда. И что мы уже давно именно так программы и разрабатываем, только называем актеров агентами. Данная ремарка является откровенной рекламой SObjectizer-а ;)

Disclaimer: я рассказал то, что воспринял из интервью Matz-а. Далеко не все я пересказал. И я далеко не уверен, что все рассказал правильно. Так что переадресую всех интересующихся к первоисточнику ;)

вторник, 26 января 2010 г.

[life] Маразм крепчал: любо учи, либо лечи

Я далек от медицины, тем более российской, но от чтения таких вещей становиться страшно: Работа лечебного центра, или скандал в благородном семействе.

В очередной раз вспоминается анекдот “…но ехать надо!” И не в Россию.

[comp.prog] Новая конструкция across в языке Eiffel

Бертранд Мейер рассказал в своем блоге о новой конструкции across в языке Eiffel, которая выполняет роль цикла foreach, но не только.

Вот так теперь может записываться обход всех элементов контейнера:

across s as c loop print (c.item) end

А вот так подсчет суммы всех элементов контейнера:

across s as c from sum := 0 loop sum := sum + c.index * c.item end

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

from
   sum := 0 ; s.start
until
   s.after
loop
   sum := sum + s.index * s.item
   s.forth
end

В качестве s может использоваться объект любого класса наследника ITERABLE. В качестве c будет использоваться объект того типа, который возвращает метод new_cursor объекта s. По умолчанию это тип ITERATION_CURSOR, но конкретный контейнер может использовать и наследников от этого класса.

Вот так можно обойти контейнер в обратном порядке:

across s.new_cursor.reversed as c loop print (c.item) end

Мейер говорит, что в Eiffel встраивается некоторая защита от модификации контейнера, по которому идет итерация посредством across. В этой защите каким-то образом задействовано постусловие и новое свойство контейнеров is_valid. Вроде бы, когда контейнер модифицируется, его свойство is_valid возвращает false вместо true и это останавливает цикл. Но как это реально работает я не понял, а сама новая версия библиотеки EiffelBase с поддержкой is_valid еще не готова.

Однако, самое интересное в across то, что эта конструкция может использоваться не только в качестве цикла, но и в качестве предиката. Например, выражение:

across s as c all c.item > 0 end

будет истинным только если все элементы контейнера s больше нуля. А выражение:

across s as c some c.item > 0 end

будет истинным если хотя бы один элемент контейнера s больше нуля.

Забавный все-таки язык Eiffel. И развивается забавно.

[comp.prog.thoughts] “Изучали XYZ прямо по ходу проекта. Несмотря на это…” Несмотря или благодаря?

Довольно часто евангелисты какой-нибудь технологии приводят примеры следующего рода: “Когда мы начинали проект большинство разработчиков даже не знали XYZ и учились по ходу работы. И даже несмотря на это проект был сделан качественно и в срок…” Об этом упоминают, когда говорят о разработке софта для AXD301, об использовании Erlang-а в Facebook. Да и я говорил (говорю и буду говорить) подобные вещи о библиотеках Qt, ACE и SObjectizer. Ибо очень удобно: мол, ну такая хорошая технология, что берешь новичка, он ее влет осваивает и пишет качественный код, так что не тормози – бери сразу два и будет тебе щасте ;)

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

Не так все просто, поскольку есть фактор новизны. Вот что об этом говорят ДеМарко и Листер в книге “Человеческий фактор” (русское издание 2005 года, стр.135):

Весной 1932 года эксперты по производительности провели ряд испытаний в Hawthorne Western Electric Company, чтобы определить влияние различных параметров среды на производительность. Они пробовали увеличивать освещенность и заметили, что производительность увеличилась. Затем они попробовали снизить освещенность и заметили, что производительность увеличилась еще больше. Они предположили, что если отключить свет совсем, производительность выбьет потолок. Было похоже, что влияние оказывает не изменение, но сам его факт. Людям было приятно, что на них обращали внимание, их интриговала новизна. Явление получило название эффекта Готорна (Hawthorne Effect). Грубо говоря, люди работают лучше, когда пробуют что-то новое.

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

понедельник, 25 января 2010 г.

[comp.prog] Ссылки от читателей: OCaml в Jane Street

Ув.тов.Rustam дал в комментарии к одной из предыдущих заметок ссылку на сайт компании Jane Street Capital, в которой активно используется OCaml: http://www.janestreet.com/technology/ocaml.php

На этой странице перечислены три PDF-ки с описанием того, как Jane Street пришла к использованию OCaml, что хорошего в OCaml, что плохого, чем им OCaml помог.

Первая PDF-ка, Caml Trader: Adventures of a functional programmer on Wall Street (2006 год) – это слайды презентации с конференции Commercial Users of Functional Programming. Такой небольшой, в виде тезисов, рассказ. Кроме того, там приведен объем написанного в Jane Street OCaml-овского кода – на 2006 год это 250KLoc (учитывая, что OCaml-овский код в 1.5-2.5 раза компактнее C++ного, это вполне внушительная цифра).

Две следующие PDF-ки, Caml Trading: Experiences in Functional Programming on Wall Street (2007 год) и Caml trading: experiences with functional programming on Wall Street (2008 год), по сути, являются раскрытием тезисов из первой презентации. Причем обе настолько похожи между собой, что при беглом просмотре не понятно, чем они друг от друга отличаются.

В кратце, суть такова: была маленькая, никому не известная трейдинговая компания Jane Street, у которой в 2003 году даже не было клиентов. Софт у нее был написан, в основном на Excel-е и VB (плюс еще что-то на C#, Java и C++). Поскольку Excel+VB не справлялись с возрастающим объемом торгов, то нужно было переходить на что-то более быстрое. Попытки использовать C# не увенчались успехом, зато OCaml эпизодически применялся в Jane Street с 2002-го года и в 2005 руководство дало добро на его широкомасштабное применение. С тех пор OCaml является основным языком разработки.

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

Я же заострю внимание на двух вещах.

Во-первых, как OCaml проник в Jane Street. Как я понял, основным “разносчиком заразы” ;) стал Yaron Minsky. Который получил PhD в области распределенных систем в Cornell, потом около года работал консультантом (в том числе и на Jane Street), а затем перешел в Jane Street на постоянную работу. OCaml он использовал еще в Cornell-е, потому и подвинул его в Jane Street. Но важнее как раз сам факт наличия PhD – я давно подозревал, что для успешного использования функциональных языков нужна ученая степень ;)

Во-вторых, в каждой из трех перечисленных работ подчеркивается один и тот же важный момент: OCaml помогает им набирать хороших программистов. Мол, Java-разработчиков полно и среди них есть отличные ребята, но вот как толковых найти среди толпы посредственностей – вопрос без ответа. А с OCaml все просто – раз человек программирует на OCaml, значит он уже по факту не может быть бестолковым (грубо говоря).

Так что я еще раз повторю мысль, которую озвучивал уже неоднократно: сейчас функциональное программирование выглядит очень привлекательно потому, что его применяют очень умные люди в очень ограниченных контекстах. Как только ФП проникнет в широкие массы и на OCaml/Haskell/Erlang начнут писать толпы обычных программистов, то мало никому не покажется. Если не верите – посмотрите на то, что мы уже сделали с ООП ;)

PS. Еще одно соображение не могу не высказать. OCaml в 2003-2005 действительно был вне конкуренции по сравнению с VB и C#. Тогда ведь в C# даже дженериков не было. Сейчас, возможно, преимущества OCaml над C# не так очевидны. Хотя практика показывает, что .NET для биржевых приложений – это как-то не очень… ;)

воскресенье, 24 января 2010 г.

[life.photo] Природа на фотографиях Юрия Бондера

В сегодняшней воскресной фотоподборке продолжается знакомство с творчеством замечательного фотохудожника Юрия Бондера (1967-2008). Сегодня фотографии, который были занесены автором в категорию “Природа”.

«DUNE 3.00 pm»