пятница, 23 марта 2012 г.

[prog.idiotic] В ненависти к ООП можно дойти до маразма

Свежий, совершенно фееричный комментарий к уже упомянутому мной обсуждению. Читать его можно и целиком, но я выделю самый яркий фрагмент:

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

Долбоебизм на марше, одним словом.

Похоже, нужно вводить какой-то отфильтровывающий барьер. Например, если человек не прочел первую треть книги “Объектно-ориентированное конструирование программ” Бертранда Мейера, то с ним об ООП можно даже не разговаривать.

[prog.work.flame] Следуя правилам чужого блога

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

Первая ветка обсуждения, начатая здесь, пришла к такому итогу:

  • thesz: Я думаю, что на Cobol нет интересной работы. Как её скоро не будет и на ООП.
    • eao197: На примере недавней вашей вакансии в ПроСофте видно, что интересная с вашей точки зрения работа не способна заинтересовать толковых разработчиков материально. Более того, сам факт вашего ухода из ПроСофта демонстрирует, что инересная работа вне ООП не интересна даже вам самим.

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

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

Отвечаю следующее:

Не суть важно, сколько вы сейчас получаете и насколько вам интересна ваша нынешняя работа. Я не находил интересным ни то, чем вы занимались в ПроСофте, ни размер зарплат, который там предлагался. Я не нахожу интересным то, чем вы занимаетесь сейчас. Это означает, что отношение к работе у нас с вами совершенно разное. И тот факт, что ПроСофт не смог быстро закрыть вакансию Хаскель/C# разработчика дает мне основание полагать, что мое отношение к работе, несколько ближе к “среднему по больнице”, чем ваше. Посему и к вашим прогнозам на будущее я отношусь более чем скептически.

Вторая ветка, начатая здесь, пришла к такому итогу:

  • eao197: Тот, кто поносит ООП не сможет применять ООП успешно. Тем самым, он будет работать хуже, чем тот, кто относится к ООП спокойно. Чем больше будет тех, кто работает хуже, тем более востребованны будут те, кто работает лучше.
    • thesz: Это очередной логический скачок.
      • eao197: Это не скачок, это наблюдение. Не доводилось видеть, чтобы люди достигали успеха используя инструменты, которые им не нравятся до такой степени, что они называют их говном.
        • thesz: Вот именно. Успеха добиваются, используя полезные и приятные инструменты. Это не отменяет способности применять инструменты, который применяющий считает... удобрением.

          Так что у вас налицо скачок в рассуждениях. Это не может быть закрыто "наблюдением".

Отвечаю следующее:

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

Ну и еще раз, чтобы дважды не вставать, объясню свою фразу “Радует число людей, которые считают ООП говном. Чем больше вас будет, тем сложнее будет остаться без работы.” (хотя считаю, что лучше всего она объясняется байкой с bash-а). Для этого отошлю читателей к своей же заметке, ко второй ее половине, начинающейся с абзаца:

В-четвертых, раздражает непонимание того факта, что завтрашнее будущее программирования определяется вовсе не тем, что сегодня выдумывают ученые в области computer science. Т.е. то, чем обычный разработчик будет заниматься, зависит не от сегодняшнего state of the art, а от того, на чем начали писать очередную промышленную систему вчера, если не позавчера.

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

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

[work.book.humour] Прочитал “Повадки обезьян”

К сожалению, не читал эту книгу раньше, но лучше поздно, чем никогда.

Очень понравилось. Местами весьма характерное поведение.

PS. Я не нарочно такой лаконичный отзыв написал, чесслово ;)

четверг, 22 марта 2012 г.

[life.humour] И что же гласит закон?

Или он просто гласит? Ну гласит себе и гласит ;)

[prog] Нашел баг в OTL

Некоторые 32-битовые ODBC-драйвера (например, производства Oracle) не поддерживают 64-битовых целых чисел (т.е. не могут работать с bigint-ами). В библиотеке OTL для таких случаев есть обходной маневр: группа макросов OTL_BIGINT, OTL_BIGINT_TO_STR и OTL_STR_TO_BIGINT. Если их должным образом определить, то OTL автоматически заменяет работу с 64-битовыми числами на работу с их строковыми представлениями. И приложение даже не замечает, что ему приходится работать с ущербным ODBC-шным драйвером.

К сожалению, в версиях OTL до 4.0.257 включительно, комбинация из OTL_BIGINT/OTL_BIGINT_TO_STR/OTL_STR_TO_BIGINT и OTL_ODBC/OTL_ODBC_MULTI_MODE не обрабатывалась должным образом. Не производилось преобразования чисел в строку и обратно.

К счастью, OTL – это OpenSource-библиотека. И хотя там достаточно своеобразный подход к организации кода (вся библиотека – это один большой h-файл), но удалось весьма быстро найти как причину проблемы, так и способ ее устранения.

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

PS. Все-таки библиотеки с полными исходниками есть рулез! :)

PPS. А по поводу качества Oracle-вских продукт пердело поделок я еще скажу пару ласковых.

[prog] ICU 49 Released

Вышла версия 49 (или 4.9, если следовать старой системе нумерации версий) большой библиотеки ICU – инструмента для работы с Unicode и другими связанными с интернализацией (i18n) вещами (числами, датами, текстами, регулярными выражениями и пр.).

Загрузить можно отсюда: http://site.icu-project.org/download/49

Тем, кто не знаком с ICU, можно заглянуть сюда: http://userguide.icu-project.org/

Список изменений весьма большой:

Common Changes

  • Unicode 6.1: New scripts & blocks; changes to grapheme break & line break property values; some characters change from symbol to Po or No; etc.
  • CLDR 21.0.1: Changes in segmentation data to match Unicode 6.1; new structures for support of Chinese calendar, for context-dependent capitalization, for gender of lists of people, for ordinal categories, and for multiple number systems per locale; deprecation of "commonlyUsed" element in timezone names; removal of "whole-locale" aliases; major cleanups of timezone names, delimiter data, abbreviated number data.
  • Normalizer2 API additions
    • Easier-to-use getInstance() variants; e.g., getNFDInstance() (#8246)
    • Getter for the combining-class value for a code point (#8606)
    • Getter for the raw Decomposition_Mapping (#8804)
    • Pairwise composition (#8804)
  • TimeZone class: (C++) Getter for unknown time zone, (Java) fields for GMT & unknown zone (#8779)
  • Support for deprecation of the "commonlyUsed" element for CLDR metazones (#8811)
  • DateTimePatternGenerator can now use separate patterns for skeletons that differ only in MMM vs MMMM or EEE vs EEEE,  etc. (#7930)
  • Support for custom DecimalFormatSymbols in RuleBasedNumberFormat (#8940)
  • Format and parse Chinese calendar dates including support for intercalary months (#8958, #8959, #8977)
  • Context Transforms for context-dependent capitalization behavior (#9110)
  • APIs for TimeZoneNames and TimeZoneFormat (#8512, #8513)
  • Support for new date format pattern "ZZZZZ" for ISO 8601 zone format (#9045)
  • Options for ambiguous local time resolution in Calendar (#8916)
  • Support for ISO 4217 numeric currency code (#7964)

ICU4C Specific Changes

  • One platform.h file used on all platforms now (#8452)
  • Smaller binaries with static-linked ICU (#8453)
  • Explicit constructors in UnicodeString (#7877)
  • Option for not including utf headers (#8575)
  • Added function u_printf (#8579)
  • C++ namespace support (#8680)
  • DateFormat/SimpleDateFormat format/parse const methods are really const now (#8844)
  • Service Provider: link against multiple ICUs, access using just locale ID for collation and date formating services (#8157)

PS. Сам я ICU не использую, но за развитием подсматриваю :)

среда, 21 марта 2012 г.

[prog.crypto] Склерозник: godzilla crypto tutorial

Когда-то давным-давно, когда пришлось познакомиться с SSL и основами криптографии, наткнулся на интересный ресурс: домашнюю страничку Питера Гатманна (Peter Gutmann).

Помимо прочего он написал и выложил в сеть большой набор PDF-ок со слайдами на тему информационной безопасности и криптографии: godzilla crypto tutorial. Помнится, я почерпнул оттуда много полезного. Так что с удовольствием рекомендую.

Кроме того, Питер разработчик большой C++ной библиотеки cryptlib. Сам я ее не применял, но в свое время смотрел. Мне она тогда понравилась больше, чем OpenSSL. (Интересующиеся так же могут глянуть на Crypto++ и Botan).

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