Здравствуй, ЛОР. Предлагаю обсудить профессию, по-английски называемую «Enterprise Architect», а по-русски — как придется, чаще всего «системный архитектор» или просто «архитектор».

Пожалуй, больше нигде я не встречал столь неоднозначного отношения к этой профессии, как на ЛОРе. Иногда в это слово вкладывается чуть ли не ругательный смысл. Я думаю, если есть критика, то есть и ее причины — а мне особенно интересно понять, как обстоят дела с этой профессией в России и странах СНГ.

И вот почему. Многие мои друзья и коллеги, оставшиеся в России (особенно молодежь), часто спрашивают меня: какими я вижу перспективы развития молодого талантливого программиста? Вопрос закономерный — всю жизнь работать программером не будешь. У этой профессии есть весьма ощутимый потолок, как в смысле финансов, так и в смысле развития. (К тому же, в последние годы профессия стремительно теряет престиж, но это тема для отдельного обсуждения.) Общепринятое мнение на эту тему таково, что для программиста есть два карьерных пути: управленческий и экспертно-технический. Иными словами, либо идти в проджект-менеджеры и выше, либо — в архитекторы. Но насколько это актуально для реалий российского IT XXI века? Если с управленцами все более-менее понятно, то какова роль архитектора? Давайте выясним.

Начну с себя. По многолетнему опыту работы им самым, могу сказать, что «архитектором» эта профессия называется не зря. Параллелей со строительством очень много. Только обычный архитектор делает чертежи зданий, а enterprise architect — «чертежи» программных систем, в общепринятой нотации (чаще всего UML), понятной всем IT-специалистам. «Строительные материалы» (технологии) выбирает архитектор, в соответствии с требованиями. В задачи enterprise architect также входит работа с аналитиками и постановщиками (чтобы понять, что именно чертить), с проджект-менеджером и разработчиками («прорабом» и «строителями»). В процессе разработки — непрерывный контроль за тем, чтобы «строители» клали «кирпичи» в четком соответствии с чертежами. В некоторых случаях архитектор берет на себя реализацию исключительно сложных частей программы. Определение требований к аппаратному обеспечению, планирование развертывания, контроль за его осуществлением, планирование нагрузочных и функциональных тестов — все это архитекторские задачи. В последнее время стали востребованы freelance architects, т.е. архитекторы по контракту, на один проект. По своему опыту могу сказать, что эта схема является выигрышной для обеих сторон. Работодателя избавляет от необходимости содержать дорогостоящего специалиста в промежутках между проектами (ведь такие промежутки могут составлять месяцы и годы). А архитектора освобождает от корпоративного рабства и позволяет ему работать в режиме полгода на проект — полгода на хорошую жизнь (отдохнуть, попутешествовать, заняться творчеством, наукой, преподаванием и т.п.)

Но, оговорюсь, это все сугубо европейский опыт. А как дела обстоят в России и СНГ? Как ты считаешь, ЛОР? Действительно ли архитектор — это необходимая профессия, вершина развития программиста по техническому пути, ключевая позиция при разработке крупных систем? Или же это бездельник, обвешанный фантиками-сертификатами, сыплющий баззвордами и получающий деньги ни за что?

Всем привет. Как поживаешь, /development/ ЛОРа? Давно не писал, но мое внимание привлекла одна проблема (присущая, вообще говоря, не только ЛОРу, но на ЛОРе проявляющаяся ярче всего). Речь пойдет о пресловутом «enterprise» (иногда в юмористическом написании «enterpriZe», «ынтырпрайз» и так далее).

В том, что «enterprise» стал на ЛОРе эдаким жупелом, смоляным чучелом — ничего странного и страшного нет. У неспециалистов это слово в первую очередь ассоциируется с корпоративным, капиталистическим, пиджачно-галстучно-кофеварочным. А отрицание корпоративного — очень в духе современной молодежи, чей природный нонконформизм требует реализации. Но это не есть предмет сегодняшней беседы; оставим юношеский нонконформизм социологам и психологам.

Проблема в том, что сам технический термин «enterprise-технологии» часто трактуется неверно. Распространено множество дилетантских интерпретаций (например, «ынтерпрайз ≡ copy-paste» и так далее). Как человеку, не один десяток лет проведшему в пресловутом «enteprise», мне хотелось бы расставить точки над «i».

Итак, ПО и технологии уровня предприятия («enterprise software») характеризуются в первую очередь повышенными нефункциональными требованиями (non-functional requirements, NFR). Что это означает? NFR относятся к работе системы, а не к её специфическому поведению (которое описывается функциональными требованиями). Рассмотрим типичные NFR:

• производительность (performance);
• масштабируемость (scalability);
• доступность (availability);
• надежность (reliability);
• безопасность (security);
• расширяемость (extensibility);
• управляемость кода (maintainability);
• управляемость системы (manageability)

и так далее. По этим признакам определенные технологии и языки программирования могут быть отнесены к «enterprise» или «non-enterprise». Например:

• Java-технологии специально разрабатывались как enterprise и максимально удовлетворяют перечисленным NFR;
• у языка Си отличная производительность, но отсутствует ООП, отсюда проблемы с абстракциями, управляемостью и расширяемостью. Плюс прямая работа с памятью и проблемы безопасности;
• C++ предоставляет ООП, но не решает проблем с безопасностью;
• Python и Ruby обладают хорошим ООП, но, не имея качественных JIT-компиляторов, сильно проигрывают по производительности. См. историю с Твиттером и Ruby vs. Scala;
• Haskell имеет немасштабирующийся GC; функциональный подход не дает таких возможностей для decoupling'а и модуляризации, как ООП. Следствие — неуправляемый и плохо расширяемый код;
• Лиспы имеют целый букет проблем, начиная от производительности, проходя через масштабируемость и заканчивая управляемостью.

Разумеется, такое деление «enterprise / non-enterprise» в известной степени условно. Например, можно и на Java нагородить неуправляемой, немасштабируемой и дырявой лапши. С другой стороны, наверное, можно и в рамках лиспа придерживаться строгой модуляризации, а коммерческие реализации дадут хорошую производительность и масштабируемость. Однако, такой подход не принят в лисп-среде (там приняты шестиуровневые квазицитирования), и подобный код будет считаться «non-lispy crap».

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

С пламенным приветом,
ваш Кукинштейн

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

Первое. Как было справедливо замечено, UML-диаграммы и инженерные схемы/чертежи служат в общем идентичным целям. Но есть одно архиважное различие. В электронике без принципиальной схемы можно спаять максимум детекторный приемник; в строительстве без чертежа можно соорудить только сарай-скворечник. Для любой мало-мальски серьезной затеи приходится прибегать к графической нотации, это абсолютно нормально и не вызывает претензий. С software engineering ситуация другая. Спектр программных решений невероятно широк, а UML оправдывает себя в довольно узкой (хоть и очень масштабной) нише. Как правило, это - программные системы уровня предприятия, где: а) существенным образом используется ООП, б) фигурирует большое количество персистентных бизнес-сущностей и связей между ними, в) есть четкое деление системы на «ярусы» (tiers), г) систему разрабатывает большая команда, д) есть строгие требования к документации. Для проектирования игр, музыкальных плееров или научного софта UML мало полезен. Так вот, проблема в том, что подавляющее большинство крикунов о ненужности UML не имеют никакого отношения к разработке ПО уровня предприятия. Точнее, имеют враждебное отношение; одни подсознательно понимают, что эта область для них недостижима (вследствие низкой квалификации); другие презирают enterprise за то, что якобы enterprise «убивает искусство в программировании и поощряет ремесленничество» (позволю себе не комментировать эту точку зрения); третьи не признают все корпоративное (в том числе и ПО) из чистого нонкоформизма. Далее, негативное отношение к корпоративному ПО переносится на UML - вот и разгадка. Добавим сюда так любимый лисперами «Blub paradox»: понимающий UML смотрит «сверху вниз» и видит возможности его успешного применения, непонимающий - смотрит «снизу вверх» и видит угрозу, как от всего непонятного.

Второе. Тезис о том, что лучшим инструментом проектирования/документирования является словесное описание и сам исходный код. Исходный код не годится для этих целей потому, что огромное количество (если не большинство) терминов UML просто не имеют (и не могут иметь) отражения в исходном коде. Так утверждают, опять-таки, лишь те, кто совершенно не владеет UML и счтает, что UML ограничивается лишь одной диаграммой классов. При этом про такие важные вещи как диаграмма вариантов использования (use-case diagram), диаграмма размещения (deployment diagram), диаграмма состояния (statechart diagram) и диаграмма последовательностей/взаимодействия (sequence/collaboration diagram) ВНЕЗАПНО остаются за кадром. Да, кое-что из этого можно кое-как восстановить по исходному коду, но это задача уровня reverse engineering.

Второе с половиной. Верно, что для любой UML-диаграммы возможно изоморфное текстовое описание. Но выразительность UML на много порядков выше. Как говорит один очень уважаемый Java EE специалист, «a clear, accurate, and easy-to-understand picture is truly worth a thousand words.» И я почему-то склонен ему верить. В самом деле, нарисовать диаграмму можно гораздо быстрее, чем описывать все то же словами. А «распарсить» диаграмму человеку еще проще. И не только распарсить, а увидеть «паттерны» (так ненавидимые все теми же крикунами), а также аномалии. Если электронщику сразу покажется подозрительным отсутствие развязывающего конденсатора в цепи транзистора, то опытный проектировщик сразу заметит циркулярные ссылки. Или возможность разнести иерархии интерфейсов и имплементаций в соответствии с паттерном «мост». Я уже не говорю об удобстве навигации по модели, которое предоставляют современные инструменты для моделирования. А сколько времени понадобится на то же самое с использованием только текстового описания?

Третье. Претензии к якобы «статичности» UML, неприменимости к развивающимся системам и неизбежном устаревании не выдерживают никакой критики. Высказывающим подобные претензии рекомендую курить статью о Round-trip engineering до полного просветления. RTE - пройденный этап, давно известная и обкатанная методология, распространяющаяся не только на UML, но и вообще на системы, представленные множеством гетерогенных артефактов. Вопрос поддержания актуальности UML-моделей - исключительно вопрос владения инструментами и правильной постановки процесса разработки. Нетривиальным (и, тем более, критическим) этот момент может показаться только тем, кто впервые слышит о RTE (что еще раз подтверждает мое предположение о главной причине претензий к UML - далекости от промышленной разработки ПО).

Четвертое. Атоматическая верификация по UML-моделям, точнее якобы ее невозможность. Утверждение об этом снова свидетельствует о незнании предмета дискуссии; я бы рекомендовал сперва ознакомиться с текущей ситуацией в этом плане. Однако, никто не спорит о том, что у UML в этом контексте есть свои недостатки, такие как многословность. Они были учтены в более перспективной методологии LePUS3 и соответствующем инструменте моделирования и верификации Two-tier Programming Toolkit.

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

А борцунов с UML слушать не надо. Их претензии, как показывает практика, носят исключительно нетехнический характер.

Я, прямо скажем, не то чтобы большой любитель всяких там «чанов», но эта история не обошла даже меня.

Вкратце. Некий весьма одиозный персонаж написал загрузчик/визуализатор файлов оригинального Warcraft 2. Без GUI, без AI. Выдает 16 fps. По словам автора, сильно тормозит. Код составляет от 1300 до 1600 (пациент никак не может определиться) строк на самописном DSL. Сколько занимает реализация DSL на Common Lisp, пациент умалчивает. Работа заняла полгода. Поскольку ссылки на отечественные ресурсы подобного толка здесь не очень приветствуются, сошлюсь на зарубежный сайт, к ним вроде у нас более лояльны. Интересующиеся без проблем нагуглят следы пациента на русскоязычных сайтах по фразе «LispCraft v0.1 by SNV», там его деятельность более активна и, я бы сказал, показательна.

По-моему, очень характеризует молодых лисперов-неофитов и их поделки:

• проект пишется в гордым одиночкой за несмешное время, от полугода до нескольких лет (как, например, тот же LDX Ловсанчега);
• является недоклоном чего-то древнего, во всем сливая оригиналу;
• никакой практической ценности не имеет, потому что
• смысл проекта - в самом проекте: попытаться доказать, что можно сделать realtime-стратегию на лиспе. А то, что попытка провалилась, уже никого не волнует;
• написан на самопальном вырвиглазном DSLe, без инфраструктуры, библиотек и toolchain'а;
• работает крайне медленно;
• автор капитально упорот.

Хочу спросить: это ли то, за что боролся Луговский?

(лейтенантом, подполковником, генерал-лейтенантом - кому как угодно)

Принимаю поздравления.

Неофициальные источники утверждают, что сабж завелся на Хабре.

Конечно, таких «камбеков» в исполнении более-менее удачливых эпигонов уже были десятки, но этот либо очень качественно исполнен, либо это действительно сабж. Судите сами: интерес к проблемам компиляторов; увлечение эзотерическими ЯП, в особенности Лисп; хорошее знание плюшек JVM; упоминание UK. И, наконец, лексика:

Вы тупое, убогое, безграмотное ничтожество.

Повторяю, свинья, проблема P=NP не имеет ни малейшего отношения к нечеткой логике. Это во первых. Во вторых, нечеткая логика имеет самое непосредственное отношение к математике.

Ну да у вас же IQ явно меньше 50, смысла вам что либо объяснять нет. Вы всего лишь убогая свинья.

Ну что Вы, что Вы, в Вас же говна — на целую роту хватило бы. Так что иначе как на Вы никак не получится.

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

И, да, не для Вас я это все пишу. Ничтожеству нельзя доказать, что оно ничтожество.

Дискасс?

Некоторые менее свежеобновленные темы неожиданно вклиниваются между более свежеобновленными.

Иллюстрация.

- В 1950 году вы написали книгу, принёсшую вам всемирную славу, - сборник рассказов «Марсианские хроники». Там говорилось: уже к началу второго тысячелетия на Марсе будут поселения, целые города землян. Как вы думаете, почему этого в итоге так и не произошло?

- Меня часто про такое спрашивают, и я люблю фантазировать над ответами. Чтобы они были разными! Ответ сегодняшнего дня: потому что люди - идиоты. Они сделали кучу глупостей: придумывали костюмы для собак, должность рекламного менеджера и штуки вроде айфона, не получив взамен ничего, кроме кислого послевкусия. А вот если бы мы развивали науку, осваивали Луну, Марс, Венеру... Кто знает, каким был бы мир тогда?

Юбилейное интервью

Вышла Vala 0.9.4, изменений по минимуму, в основном работа ведется над профилем Dova (стандартная библиотека, написанная на pure Vala). Похоже, 1.0.0 не за горами.

И да, теперь в Vala можно использовать монадические конструкции. На закономерный вопрос: «А на кой черт монады в императивном языке?» - автор ответил, что в основном это служило проверкой того, насколько гибким языком является Vala. Впрочем, один практический пример («безопасное» деление), таки да, был приведен.

Вместе с Mandriva 2010 Spring был опубликован пресс-релиз о грядущей реструктуризации. Целиком переводить лень. Суть такова:

Mandriva окажется в центре структуры, образованной французской IF Research (хозяева Wallix), LightApp (Великобритания) и Pingwin Soft (Россия).

А вот это не очень понравилось:

At the heart of this strategy, Mandriva Linux will be distributed exclusively by a sales and integrated IT network, as well through an OEM (Original Equipment Manufacturer) in the EMEA (European and Middle East) and BRIC (Brazil, Russia, India, China) zones.

В в этом контексте фраза «2010 Spring, Mandriva's latest distro» вызывает какие-то неуютные ощущения.

А вот это точно будет допиленный Mandriva Pulse 2 с саппортом:

A professional offer aimed at the major business markets (Education, Industry, Services, Retail) will meet the demands of clients seeking alternative and economic options in the field of heterogenous IT systems management. This offer will be unveiled in the second half of 2010.

Президент IF Research и Wallix уже присоединился к правлению Mandriva. Новый инвестор, равно как и новая стратегия развития, будут представлены на ближайшем заседании правления. Заметим, о NGI ни слова. Что примечательно, NGI купил акции не у самой Mandriva, а у держателей акций, так что Мандриве с этой сделки не должно было достаться ни копейки. Однако, «русский след» в виде Pingwin Soft все же имеется. Ну что, пинкертоны, копнем под Пингвина? Интересно, кто стоит за всей этой структурой.

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

Особенно отмечу то, что подобные ситуации являются наиболее «демотивирующими» для авторов, пишущих значимые, информационно насыщенные и богатые разметкой новости (которые нельзя просто так «скопипастить» из удаленных). Поэтому прошу предоставить способ просмотра исходных текстов (LORCODE) удаленных новостей, а еще лучше - всех новостей, использующих LORCODE (иногда бывает полезно повторно использовать некоторые конструкции). Или, если это затруднительно, предусмотреть альтернативный workflow подтверждения/удаления/доработки, сохраняющий доступ к исходным текстам. Спасибо.

ЛОРчанам, спрашивавшим меня - контакты для связи со мной находятся в профиле.

P.S. Ув. модераторы, пожалуйста, дайте повисеть сообщению, пока здесь не отметятся те, кто искал со мной связи. Потом удалю тему самостоятельно. Спасибо!

В свете нового курса партии на повышение качества новостного материала предлагаю организовать соцсоревнование - конкурс авторов новостей.

• Рассматривать новости по критериям стиля, оформления, грамотности, оперативности, значимости и резонанса.
• Выбирать автора месяца и автора года.
• Автора месяца награждать именной ЛОРовской футболкой, плюшевым туксом или какой-нибудь милой поделкой, которые часто появляются в галерее.
• Автора года - годовой подпиской на LinuxFormat, каким-нибудь стоящим линуксовым гаджетом и приглашением на званый обед с модераторами ЛОРа, или на свидание с Сильви. Шутка. :) Также можно награждать поездками на какие-нибудь знаковые опенсорсные мероприятия; в общем, все зависит только от фантазии.
• Опционально: годовые результаты подводить, скажем, в день рождения Торвальдса, или 1-го апреля, или в День Вебмастера, День Сисадмина или любой из двух Дней Программиста, дабы предновогодняя суета и унылая погода не помешали мероприятиям, связанным с награждением.

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

Как вам такое?

ЛОР, боже ты мой!

Помню, помню этот номер «Веселых картинок», затертый до дыр, порванный, заклеенный и снова порванный. Помню, как, едва научившись читать, по сотому разу пересматривал приключения Зои, Куки и Кваки и их самоотверженную борьбу с электрокрокодилом, а потом и сам рисовал продолжение. И вот теперь, ЛОР... (смахивая слезу) внезапно нахожу его на просторах рунета!

Еще удивительнее то, что среди сверстников, которых я порасспрашивал, многие вспомнили этот выпуск «ВК»! Некоторые запомнили только его, хотя среднестатистический ребенок восьмидесятых «проглатывал» за свои детские годы как минимум несколько десятков номеров «Мурзилки» и «Веселых картинок». Более того, было высказано мнение, что это - де-факто первый советский комикс.

А есть ли среди ЛОРовцев те, кому знакомы Кука с Квакой?

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

• ужесточить политику подтверждения новостей. Без колебаний отправлять на доработку новости, недооформленные и/или содержащие ошибки всех сортов. Не позволять полуграмотным и недопереведенным новостям попадать на главную только лишь потому, что из-за неподтверждения автор склонен устраивать истерики и угрожать «дверехлопом», или же по принципу «на безрыбье и таракан мясо»;
• повысить минимальный объем вознаграждения за те новости, которые прошли фильтр п. 1 и поощрять аппруверов выставлять высокие оценки за качественные новости;
• ввести должность «рерайтера» (извините за кальку с английского - но это вполне устоявшийся термин, можно на русский манер называть его «переписывателем» или «переписчиком»), который имел бы возможность перерабатывать новости, отфильтрованные в п. 1, и за это получать адекватную часть вознаграждения за новость. Разумеется, тут придется расщедриться на шкворц: принцип «1 балл автору и 2 - рерайтеру» здесь не прокатит, вознаграждение должно быть соответствующим и тому, кто раскопал новость, и тому, кто ее грамотно оформил.

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

Впрочем, не премину намекнуть (который раз), что ЛОР, с его-то SEO-показателями, мог бы позволить себе дюжину таких на фулл-тайме. Было бы только желание.

Последнее время на ЛОРе только и слышишь, что-де «Java завоевала популярность исключительно благодаря маркетингу и низкому уровню вхождения». Давайте же, сознательно оставив за рамками дискуссии маркетинговые вопросы, разберемся природе распространенного мифа, каковым является вторая часть этого безапелляционного утверждения.

Сперва давайте полистаем спецификацию языка Java, третье издание. В книжке 684 страницы. Шестьсот восемьдесят четыре. (Если в этот момент у вас при словах «низкий уровень вхождения» начинается истерический хохот - не пугайтесь, это как раз свидетельствует о вашей нормальности; остальным же рекомендуется продолжить чтение.) Разумеется, многие могут парировать, что, мол, совершенно не обязательно читать всю книгу для того, чтобы начать программировать. Чтобы начать быдлокодить - возможно. Но чтобы начать эффективно решать задачи, используя для этого всю мощь языка - книжечку придется все-таки как следует полистать.

Ну, что же, спецификацию языка мы изучили. Что мы можем написать на Java? Да ровным счетом ничего, потому что мы еще не освоили работу со стандартной библиотекой или (иными словами, Java API). Стандартная библиотека Java версии 1.6 состоит чуть более чем из семи тысяч классов и интерфейсов и десятков тысяч методов. Предвосхищая повторное «и зачем надо въезжать во все 7000 сразу?» - отвечу, что таки да, пишущему десктопное приложение может не понадобиться какая-нибудь CORBA, а разработчику сетевых сервисов - Swing и так далее. Но если решаемая задача все же сложнее «Hello, World!», то ее предметной области будет соответствовать некое довольно объемное подмножество Java API, которое придется освоить в полной мере.

Вот мы и научились создавать desktop-приложения, несложные сетевые службы и middleware, работать с файлами и обрабатывать XML. Что же дальше? Давайте обратим наш взор на встраиваемые приложения, где Java давно прописалась, и с большим комфортом. Мобильные телефоны, PDA, set-top boxes, автомобильные компьютеры, диски Blu-ray - это все так называемая Java Microedition. Поскольку спектр устройств (и их возможностей) невообразимо широк, настолько же широк и спектр спецификаций («профайлов») JavaME, покрывающий их: CDC (Connected Device Configuration), CLDC (Connected Limited Device Configuration), MIDP (Mobile Information Device Profile), FP (Foundation Profile), PBP (Personal Basis Profile), PP (Personal Profile). Пусть каждый из «профайлов» и является подмножеством «старшего брата» (JavaSE), но каким именно подмножеством - потребуется изучить.

Наконец предположим, мы позволили себе замахнуться на Вильяма нашего Шекспира Корпоративную Информационную Систему. Что нас ждет в этом случае? А ждет нас изучение Java Enterprise Edition. В этом дивном новом мире нас ждут сервлеты и фильтры, JSP и JSF, Tomcat и GlassFish, JDBC и JPA, JCDI и JNDI, EJB, JTA, JMS, JAAS, JCE, JSSE, и много всяких прочих интересностей. Пытливый ум задаст вопрос: «А нафига мне весь этот блоат, если я хочу автоматизацию бизнеса? SQL в руки, и вперед!» - на что я отвечу ему следующее. Построение эффективной, производительной, масштабируемой, надежной и безопасной системы потребует задействования определенных, вполне известных техник. Техника «SQL в руки, и вперед» к ним не относится. Но вам повезло: большинство подобных техник уже реализовано для платформы Java, реализации имеют высокое качество и публикуются под свободными лицензиями. Большинство вышеприведенных аббревиатур имеют к ним прямое отношение. Это и реализации ORM/Persistence (Hibernate, EclipseLink), и контейнеры для трехзвенных приложений (GlassFish, JBoss), и веб-контейнеры (Tomcat), и кластерные коммуникации, и JMS message broker'ы, и так далее, и тому подобное. Поэтому для трезвомыслящего разработчика, который заботится о качестве продукта и о своем времени, путь один: изучать технологии, чтобы потом экономить время и повышать качество продукта. И да, это требует интеллектуальных и временнЫх вложений.

Резюмируя, скажу, что уровень вхождения, необходимый для написания хелловорлда, примерно одинаков для всех языков - от примитивного Visual Basic до зубодробительного Haskell. Для решения реальных задач потребуется поработать мозгами в любом случае. Для эффективного и продуктивного решения задач - придется поработать мозгами очень конкретно. В этом смысле Java дает некоторую поблажку разработчикам (по отношению к другим языкам), за счет огромного количества технологий, решающих подчас очень сложные инфраструктурные задачи (кластеризация, persistence, remoting и т.п.). Но это не отменяет необходимости их глубокого изучения (что, как правило, воздается сторицей).

Таким образом, утверждение о том, что «Java имеет низкий порог вхождения», выдает в заявляющем представителя одной из следующих категорий:

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

Ну или любая из четырех нетривиальных комбинаций вышеперечисленного.

Навеяно предыдущей темой.

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

Факел был когда-то зажжен незабвенным Проффессором Луговскером, и достался он лиспу. Прошло несколько лет, и теперь даже самый распоследний нубас на ЛОРе расскажет вам про REPL, метапрограммирование, квазиквотацию, eval, Slime и про жаба-monkey-кодеров. Лисп стал популярен на ЛОРе, и утратил позиции «элитного» языка, дискутировать о котором могли единицы.

Ниша долго не пустовала. Некоторое время факел находился у Haskell, а последние месяцы его гордо несет Smalltalk (я сужу исключительно по количеству новостей и дискуссий о нем). Но теперь завзятые маргинальщики начинают интересоваться Forth'ом, из чего я делаю вывод о том, что факел Smalltalk'а начал коптить, в силу его популяризации на ЛОРе.

Предлагаю коллективно поразмыслить над тем, какой язык мог бы принять эстафету у Форта. Из маргинальных неэзотерических языков осталось не так уж и много. Clean? Pure? Factor?

Несколько навеяно свежей драмой, располагающейся топиком ниже. Нет, безусловно, я считаю подобные драмы глубоко деструктивными для ЛОРа, а истерики - странно выглядящими в исполнении взрослого человека. Но здравое зерно из той некрасивой истории вынести все же можно: в подтверждении новостей имеет место определенный бардак.

Не может не радовать то, что с бардаком уже начали бороться: я имею в виду отмену начисления score за копипасту с опеннета. Я считаю, что было бы неправильным останавливаться на этом (к тому же, это лишь только «кнут» в потенциальной связке кнута и пряника). Поэтому я предлагаю ввести механизм, гарантирующий высокое вознаграждение качественным новостям.

Ни для кого не секрет, что на крупных, посещаемых интернет-ресурсах пользователи готовы сделать все, что угодно за звезды, баллы, очки, лычки и прочие виртуальные малиновые штаны. (Точно таким образом Одноклассники.ру, например, набрали себе бесплатный штат модераторов фотографий.) Давайте посмотрим правде в глаза: на ЛОРе такими малиновыми штанами являются score и звезды. За них пользователи пойдут на все. И я предлагаю не лицемерить и не отрицать это, не манерничать в духе «ах, оставьте, звезды - не показатель крутизны, и шкворц - это не главное», а повернуть ситуацию во благо ЛОРа.

Известно, что модератор, подтверждающий новости, на свое усмотрение начисляет автору вознаграждение в размере от 0 до 20 баллов, причем по умолчанию начисляется три балла. Мой опыт ньюсмейкерства на ЛОРе показывает, что данной опцией пользуются один-два подтверждающих модератора, остальные элементарно ленятся выставлять недефолтное значение. Поэтому можно потратить, скажем, час времени на грамотное оформление новости, а получить за нее все те же три балла - тут действует принцип «на кого нарвешься». Мое рацпредложение заключается в следующем: требовать от аппрувера выставления оценок новости по следующим критериям: язык (грамотность + стиль), оформление, актуальность, точность, значимость/интерес. Это может быть простой интерфейс в виде нескольких линеек со звездочками (а-ля рейтинг композиции в Rhythmbox), нескольких групп radio-button'ов, нескольких select'ов и так далее, который бы на основе накликанных аппрувером значений вычислял бы рекомендуемый размер вознаграждения.

Что принесет ЛОРу такая модификация? Ньюсмейкеры будут стремиться к более качественной подаче информации. Каковы негативные стороны? Помимо модификации (впрочем, несложной) движка, понадобится найти аппруверов, которые были бы способны к адекватной оценке новости по всем вышеперечисленным критериям. То есть такой человек должен быть грамотным (в смысле русского языка) и иметь чувство стиля, и в то же время быть подкованным технически, для оценки значимости новости. Как показывает практика, таким сочетанием качеств обладает не так много людей, а особенно почему-то на ЛОРе. Впрочем, оценку «интересности» новости можно возложить на пользователей. Нет, разумеется, не при помощи кармы, а элементарно по количеству комментариев, которое новость собрала. Правда, начислять вознаграждение в таком случае придется постфактум, при автоматическом «запечатывании» топика по прошествии времени.

Если вышеописанная схема кажется сложной, то можно хотя бы ввести ежемесячный конкурс ньюсмейкеров, с призовым фондом, скажем, 50 шкворца. А вообще, как справедливо кто-то заметил недавно, при таких тИЦ и посещаемости, как у ЛОРа, да при желании/умении всем этим заняться, можно было бы зарабатывать по два новых сервера каждый месяц. И даже позволить себе штат профессиональных ньюсмейкеров/корректоров/аппруверов.

Впрочем, это уже не мое дело.

Почитывал на досуге всякие материалы о DRM. В качестве основного критического тезиса везде выдвигается примерно следующее:

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

Мне вышеописанная ситуация что-то смутно напоминает. А вам?

Которую неделю вокруг Mandriva кипят страсти несусветные, релиз задерживается почти на месяц, а тут в рассылку как ни в чем ни бывало приходит такое:

Get Mandriva's DVD case and Mandriva's Tux plush at a great price!

You may know the Linux mascot : the Tux plush. You can now adopt it thanks to Mandriva at a great price for an exceptional offer which last 15 days, starting today:

Mandriva Powerpack 2010 slim pack 2 DVDs + Mandriva Tux plush for only 39.9 EUR (For the English version: 39.9 EUR / USD 49.9)

Enjoy immediately this offer and receive your plush into three to five days by clicking on this link: http://store.mandriva.com/product_info.php?cPath=63&products_id=496

Mandriva Team

Так вот она, новая экономическая модель! Оказывается, таинственный инвестор - Донецька фабрiка iграшек!