Одновременно с JDK 8 была выпущена очередная версия официальной Java IDE — NetBeans 8.0. Из нововведений:

• Java: полная поддержка Java 8; поддержка Java SE/ME Embedded; улучшения в редакторе; улучшенная интеграция с JavaFX Scene Builder.
• Java EE: кодогенерация для PrimeFaces; поддержка Tomcat 8 и TomEE; улучшения в поддержке JFS, CDI и JPA.
• Maven: улучшения в визуализации графов зависимостей; улучшения производительности.
• JavaScript: улучшения в поддержке AngularJS, Knockout и jQuery; поддержка выполнения и отладки скриптов в Nashorn (JDK 8).
• HTML5: поддержка отладки в Android 4.4 WebKit для Cordova 3.3+; поддержка Karma, Grunt и Avatar.js.
• PHP: поддержка PHP 5.5, Latte, Nette, CS Fixer, Twig, Neon.
• C/C++: поддержка breadcrumbs; консоль GDB; оптимизация работы с удалёнными проектами; новые подсказки (hints) и code completion.
• Платформа: возможность горизонтального и вертикального деления окна редактора (split view) при помощи drag'n'drop; переработанный интерфейс для Project Groups.
• Прочее: улучшения в профилировщике, задачах (Tasks), поддержке Subversion.

NetBeans — среда разработки, которую Oracle позиционирует как официальную IDE для Java и сопутствующих технологий. Однако, за последние годы NetBeans превратилась в мощную мультиязычную среду разработки. Официально поддерживаются Java, Groovy, C/C++, HTML5/JavaScript и PHP. Сторонними разработчиками поддерживается широчайший спектр языков программирования: от промышленных (Python, Ruby, Scala) до обучающих (Лого) и экзотических (LambdaBeans для Scheme). От других аналогичных IDE NetBeans выгодно отличают свободная лицензия, бесплатное распространение, всегда актуальная поддержка стандартов Java и эргономичный, не перегруженный и интуитивно понятный интерфейс.

NetBeans также является платформой для разработки комплексных desktop-приложений. В этом качестве NetBeans активно используется в оборонной промышленности (NATO, Northrop Grumman, US Navy), геодезии и картографии (Saab Systems Grintek), авиационной индустрии (Boeing), логистике, аграрной промышленности, разработке полезных ископаемых, образовании, телеком-индустрии, финансах, науке, инженерии и искусстве.

Краткий обзор новой версии

Подробный обзор

>>> Сайт проекта

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

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

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

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

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

Вышла новая версия среды разработки NetBeans IDE. Новый выпуск включает в себя следующие новшества и улучшения:

• Java: поддержка лямбда-функций из JDK 8; улучшены рефакторинг, code completion и подсказки, улучшения в поддержке JavaFX;
• HTML5: поддержка Cordova и мобильных браузеров, быстрое переключение браузеров из тулбара, монитор сети;
• JavaScript: поддержка фреймворков AngularJS, Knockout and ExtJS; навигация и code folding для JSON-документов, улучшения в code completion;
• Java EE: вся функциональность HTML5 теперь доступна в проектах Java EE;
• PHP: полнофункциональный HTML5 в PHP-проектах; поддержка фреймворков Nette и Zend Framework 2, улучшен рефакторинг и статический анализатор кода;
• C/C++: индивидуальные стили форматирования для проектов; улучшения в Find Usages;
• Прочее: новая эргономичная панель задач; оффлайн-режим для Bugzilla; улучшена поддержка Subversion/Git/Mercurial и СУБД.

NetBeans — среда разработки, которую Oracle позиционирует как официальную IDE для Java и сопутствующих технологий. Однако, за последние годы NetBeans превратилась в мощную мультиязычную среду разработки. Официально поддерживаются Java, Groovy, C/C++, HTML5/JavaScript и PHP. Но благодаря сторонним разработчикам поддерживается широчайший спектр языков программирования: от промышленных (Python, Ruby, Scala) до обучающих (Лого) и экзотических (LambdaBeans для Scheme). От других аналогичных IDE NetBeans выгодно отличают свободная лицензия, бесплатное распространение, всегда актуальная поддержка стандартов Java и эргономичный, не перегруженный и интуитивно понятный интерфейс.

NetBeans также является платформой для разработки комплексных desktop-приложений. В этом качестве NetBeans активно используется в оборонной промышленности (NATO, Northrop Grumman, US Navy), геодезии и картографии (Saab Systems Grintek), авиационной индустрии (Boeing), логистике, аграрной промышленности, разработке полезных ископаемых, образовании, телеком-индустрии, финансах, науке, инженерии и искусстве.

Краткий обзор нововведений

Подробности о новой версии

Видеообзоры новой версии

>>> Сайт проекта

Всем привет. Как поживаешь, /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».

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

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

Этим летом произошло событие, которое досадным образом осталось незамеченным на linux.org.ru. Вышла версия 2.2 платформы JavaFX, начиная с которой заявлена официальная поддержка Linux и Mac OS X. Помимо этого, были реализованы следующие новые возможности:

• canvas — тип узла (node), допускающий непосредственное рисование в стиле HTML Canvas;
• snapshots — возможность «сфотографировать» часть scene graph'а и поместить «снимок» в изображение;
• writable images — возможность прямой манипуляции пикселами

и многое другое. Изменения коснулись и принципа распространения JavaFX — отныне JavaFX является неотъемлемой частью Java SE, и они будут распространяться вместе (начиная с Java 7u6 + JavaFX 2.2). Более того, следующая «большая» версия JavaFX будет носить номер 8, а затем JavaFX вообще утратит собственную версию, окончательно влившись в Java SE. Также успели выйти корректирующий релиз 2.2.3, preview-релиз для аппаратной платформы ARM (на базе Java SE Embedded) и preview визуального построителя интерфейсов Scene Builder.

JavaFX — современный кроссплатформенный тулкит для создания десктопных и интернет-приложений с использованием технологий Java, все чаще рассматриваемый как замена устаревающему Swing. JavaFX активно использует мощности графических ускорителей, поддерживает декларативное описание интерфейсов (FXML) и множество мультимедиа-форматов. Начиная с JavaFX 2.x, возможности этого тулкита открыты для всех без исключения JVM-языков: собственно Java, а также Scala, Groovy, Clojure и так далее. Разработка JavaFX ведется в рамках открытого проекта OpenJFX.

Сообщение о выходе JavaFX 2.2

>>> Сайт JavaFX

После разработки, длившейся больше года, вышла вторая версия платформы для создания интернет-приложений JavaFX. Эта технология имеет давнишнюю историю: будучи созданной в 2007 году под названием «F3», успела претерпеть несколько релизов, а также поменять название и хозяев. Сегодняшний JavaFX - достойный ответ Oracle таким технологиям как Adobe AIR и Microsoft Silverlight. Это подразумевает быструю и эффективную 2D- и 3D-графику, использующую аппаратное ускорение; векторную анимацию, построенную на принципах keyframe и tweening; эргономичный набор виджетов; запуск как в браузере, так и через Java Web Start; возможность инсталляции в качестве desktop-приложения; возможность использовать современные мощные языки программирования.

Ключевым моментом версии 2.0 является то, что вся функциональность JavaFX доступна теперь в виде обычных Java API. Если раньше единственным языком для JavaFX являлся FXScript, то теперь платформа JavaFX открыта для всего спектра JVM-языков: Java, Scala, Groovy, JRuby, Jython, Clojure, Mirah, Fantom и другие; почетное место в списке занимает Visage - достойный наследник FXScript. Авторы JavaFX надеются, что этим списком будут удовлетворены сторонники даже самых экзотических тенденций в программировании. Остальные важные моменты релиза 2.0 вкратце перечислены ниже; подробнее ознакомиться с ними можно по ссылке.

( читать дальше... )

О выходе JavaFX 2.0 было объявлено вчера на конференции JavaOne'2011 в Сан-Франциско. Разработчики пообещали в скором времени открыть исходные тексты всей платформы JavaFX в рамках проекта OpenJDK. Помимо этого, были озвучены небезынтересные идеи касательно будущей Java 9, такие как реификация, оптимизация хвостовых вызовов, продолжения (continuations) и метаобъектный протокол (MOP).

В данный момент доступна стабильная версия под Windows, Developer Preview под Mac OS и альфа версия под Linux. Стабильная Linux версия ожидается в 2012.

>>> Подробности

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

Первое. Как было справедливо замечено, 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'а;
• работает крайне медленно;
• автор капитально упорот.

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

Аналитическая компания TIOBE Software опубликовала итоги своего исследования популярности языков программирования за 2010 год.

Наибольшую динамику продемонстрировали Python, Objective-C и PHP. Первый увеличил свою долю на 1.81%, перепрыгнув с 7-го места в 2009 году на 5-е. Предположительно, объясняется это тем, что Python продолжает завоевывать прочные позиции как язык для написания системных скриптов и настольного ПО. Objective-C продемонстрировал прирост на 1.63%, поднявшись с 12-го места на 8-е; это связывают с растущей популярностью устройств, работающих под управлением Apple iOS. Наконец, PHP потерял 2.24%, опустившись на 4-е место с 3-го. Это, возможно, обусловлено с вытеснением PHP из ниши веб-программирования более современными языками и платформами. Теряют свои позиции VisualBasic, JavaScript, Perl и Delphi.

Сотрудники TIOBE подчеркивают, что составляемый ими рейтинг не основывается на количестве строк кода, написанных на каком-либо языке в 2010 году, и не претендует на то, чтобы служить показателем качества, мощи или распространенности языка программирования. Рейтинг TIOBE основывается на статистике поисковых запросов, предоставляемых Google, Wikipedia, Yahoo и подобными службами. Вследствие этого, правильнее рассматривать рейтинг TIOBE как некую характеристику трендов и моды в выборе языков программирования. Так, например, завидную статистику продемонстрировал Lisp, прибавив 0.53% и совершив скачок с 18-го места на 13-е.

Языком года был признан Python, благодаря исключительной динамике и успешному завоеванию новых ниш. Первые три строчки рейтинга вот уже несколько лет стабильно занимают Java, C и C++, демонстрируя нулевую или невысокую положительную динамику.

>>> Подробности

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

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

Сайт SecurityReason сообщает об обнаружении опасной ошибки в реализации библиотечной функции glob() из стандартной библиотеки языка C (libc) на множестве платформ.

Эта функция предназначена для получения списка файлов, чьи имена удовлетворяют заданному шаблону. Ошибка заключается в том, что ограничение на выдачу функции, задаваемое переменной GLOB_LIMIT, не действует в случае задания некорректных путей в шаблоне. Такими некорректными значениями могут быть, например, «*/../*/../*foo» или «{..,..,..}/*/{..,..,..}/*bar». При этом вызов функции glob() может исчерпать всю доступную память процесса.

Особенную опасность данная ошибка представляет для (S)FTP-серверов, особенно с разрешенным анонимным доступом. Очевидно, запрос на листинг файлов с вышеприведенной маской приводит к скорому отказу в обслуживании FTP-сервера.

Уязвимости подвержены, по последним данным, как минимум следующие ОС: OpenBSD 4.7, NetBSD 5.0.2, FreeBSD 7.3/8.1, Oracle/Sun Solaris 10, а также все версии Linux с GLIBC. Уязвимость пока что устранена только в NetBSD; компании и сообщества, занимающиеся разработкой вышеперечисленных (за исключением NetBSD) операционных систем, пока не дают никакой информации; именно поэтому уязвимость классифицируется как «0-day». Сообщается также, что vsftpd не подвержен уязвимости.

>>> Подробности

Вышла версия 0.11.0 перспективного языка программирования Vala.

В версии 0.11.0:

• использование байтового типа для индексирования строк;
• поддержка параллельной компиляции (при помощи скрипта contrib/parvala);
• улучшение производительности компилятора;
• переработан кодогенератор.

В предыдущих версиях, не освещенных на LOR (по 0.9.2 включительно):

• упразднена конструкция string.len() в пользу string.length;
• упразднены привязки D-Bus Glib в пользу GDBus;
• введена поддержка параллельной инсталляции нескольких версий Vala;
• добавлена команда «vala» для одновременной компиляции и запуска программы;
• обновлены/добавлены привязки: glib-2.26, gdk-pixbuf-3.0, gdk-3.0, gdk-x11-3.0, gtk+-3.0, gedit-2.20, tokyocabinet;
• появилась интересная возможность использовать монады в Vala;
• огромная работа проделана над профилем Dova;
• как всегда, большое количество исправлений ошибок, рефакторинга и обновлений привязок.

Vala — сравнительно молодой язык программирования. Свой синтаксис Vala в основном заимствует у C#, но имеется Python-подобный синтаксический вариант Vala, называемый Genie. Vala позволяет разработчикам использовать современные языковые возможности, такие как свойства, сигналы, foreach, лямбда-выражения, выведение типов, автоматическое управление памятью, обработка исключений; в то же время, Vala способствует написанию производительных и эффективных программ, поскольку не требует для запуска прослойки в виде виртуальной машины, а весь Vala-код транслируется в код на языке C. Изначально Vala была предназначена для программирования в парадигме GObject, но сперва появился профиль POSIX (позволяющий писать программы, не зависящие от GLib), а теперь и профиль Dova, которому уделяется особое внимание. Dova — легковесная стандартная библиотека, написанная целиком на Vala и призванная во многих смыслах заменить GLib.

Следует также отметить, что, начиная с версии 2.32, среда разработки Anjuta IDE имеет полную поддержку Vala, включая автодополнение кода.

Сообщение о выпуске

Блог Vala

>>> Сайт проекта

Mandriva в очередной раз подтверждает свое трепетное отношение к XFCE. Загрузочный компакт-диск Mandriva One отныне будет выходить в варианте с XFCE, в дополнение к GNOME- и KDE-вариантам. Mandrive One XFCE базируется на Mandriva 2010.1 Spring (Linux 2.6.33.5, Mozilla Firefox 3.6.8, OpenOffice.org 3.2.0) и включает последнюю версию XFCE (4.6.2). Большое внимание уделено эстетической стороне:

• присутствует большое количество новых интересных обоев;
• новая тема иконок GNOME Brave;
• фирменная тема виджетов Ia Ora Steel;
• новые пиктограммы пользователей в экране входа в систему;
• множество мелких улучшений.

Что же касается программного обеспечения, то были включены:

• Evolution (вместо claws-mail);
• Ristretto — быстрый просмотрщик изображений;
• Parole и Exaile для просмотра видео и прослушивания аудио;
• все кодеки GStreamer, включая gst-plugins-ugly, что обеспечивает беспроблемное воспроизведение DVD-дисков и музыки в формате MP3.

Mandriva One — загрузочный компакт-диск с возможностью инсталляции, основывающийся на программной базе своего «старшего брата» Mandriva Free (в One присутствуют и некоторые проприетарные компоненты). Mandriva One традиционно предоставляет быстрое и легковесное окружение рабочего стола без ущерба для функциональности и набора программного обеспечения. Также доступен вариант Mandriva Flash, в котором как операционная система, так и пользовательские данные располагаются на USB-устройстве.

Обзор, спецификации, сообщение о выпуске.

Загрузить Mandriva One XFCE Edition.

>>> Сайт Mandriva

Одиннадцатый год развития открытого XSL-FO-процессора Apache FOP ознаменовался достижением версии 1.0.

По-видимому, разработчики были настолько поглощены процессом подготовки выпуска, что забыли анонсировать выпуск, который произошёл в середине лета. Тем не менее, это — знаковое событие для opensource-графики: FOP является де-факто единственным открытым и свободным процессором XSL Formatting Objects. FOP активно используется в таких серьезных организациях, как Accenture, BNP Paribas, FedEx, Европейский патентный офис, Ford, HP, IBM, Siemens, Палата Представителей и Армия США. В версии 1.0:

• адресация всех доступных глифов в шрифтах Type 1;
• автоматическое конфигурирование коллекций TrueType-шрифтов (.ttc). В файлах font-метрик для них более нет необходимости;
• рендеринг с использованием Java Print System;
• посимвольная и пословная стратегия выбора шрифта;
• начальный набор расширений для предпечатной подготовки (препресс);
• поддержка страниц разной ширины в рамках одной последовательности (page-sequence);
• поддержка пиктографических шрифтов TrueType, таких, как Wingdings или Symbol;
• фреймворк обработки событий, обеспечивающий более полное информирование о процессах в FOP.

XSL Formatting Objects (спецификация) — язык разметки типографских макетов и прочих предпечатных материалов, использующий всю мощь XML-технологий WWW-Консорциума. По идеологии XSL-FO пользователь создаёт исходный текст в виде произвольного XML (например, XHTML, DocBook или TEI), который затем при помощи XSLT-трансформации превращается в FO-документ и далее «материализуется» FO-процессором. Так, в качестве выходных механизмов Apache FOP поддерживает визуализацию на экране, вывод на печать и в файлы формата PDF/PostScript/PCL/SVG/PNG/RTF; в то же время, сам по себе XSL-FO — media-независимый язык.

Вместе с выходом Xerces-J 2.10.0 (с поддержкой XML Schema 1.1), выпуск FOP 1.0 представляет собой существенное обновление XML-стека от Apache.

Заметка на JavaLobby.

>>> Сайт проекта

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

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

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

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

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

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

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

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

Дискасс?

Не так давно вышла новая стабильная версия webmail-клиента Roundcube. Из новшеств:

• переработанный backend-код, за счет чего обещается прирост производительности;
• древовидный список сообщений (threaded message listing);
• группировка контактов;
• «подчистка» пользовательского интерфейса;
• нераспространение условий GPL на пользовательские темы. Отныне допускается создание тем под любыми лицензиями, в том числе коммерческими;
• множество исправлений ошибок.

Roundcube — перспективный webmail-клиент для служб IMAP. При разработке не в последнюю очередь уделялось внимание эргономике и эстетике интерфейса. Присутствуют поддержка HTML-сообщений, проверка орфографии, многоязыковая поддержка. При включенном JavaScript используются возможности AJAX. В качестве механизмов хранения данных предлагаются MySQL, PostgreSQL или SQLite; поддерживаются адресные книги в LDAP. Благодаря гибкой архитектуре, использующей плагины, достигается расширяемость функциональности (например, загрузка пользовательских Sieve-скриптов по протоколу ManageSieve).

Roundcube Webmail написан на PHP.

Сообщение о выпуске.

>>> Сайт проекта

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

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

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

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

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

Вышел Dovecot 2.0.0. Разработка заняла чуть больше года, выпуску предшествовали шесть бета-релизов и шесть релиз-кандидатов. В версии 2.0.0:

• полностью переработанная поддержка Sieve и ManageSieve, благодаря проекту Pigeonhole;
• переписанный master-процесс обеспечивает большую модульность и меньшее количество кода, работающего из-под root;
• гибкая конфигурация для различных IP/подсетей клиента;
• dsync — двухсторонняя синхронизация почтовых ящиков;
• LMTP-сервер и прокси;
• новый механизм хранения — mdbox (multi-dbox);
• doveadm — утилита для выполнения всевозможных задач администрирования Dovecot;
• обработка одновременных подключений процессами pop3 и imap;
• поддержка сжатия благодаря плагину imap_zlib;
• сервис director для перенаправления NFS-клиентов на заданный NFS-сервер, в целях поддержки целостности данных.

Dovecot — гибкий, надежный и функциональный POP3/IMAP-сервер, постепенно приходящий на смену «старичкам» Cyrus и Courier. Разрабатывается финским студентом Timo Sirainen при поддержке некоторых коммерческих структур. Так как проблема безопасности является традиционной для нетривиальных сетевых сервисов, то ей при разработке Dovecot уделяется особое внимание. Так, нашедшему удаленно эксплуатируемую уязвимость автор Dovecot обещает крупный денежный приз (насколько известно, не востребованный до сих пор).

Инструкция по апгрейду.

Сообщение о выпуске.

>>> Сайт проекта

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

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