A Comparison of Qt and Java
Автор: Matthias Kalle Dalheimer
Перевод: Andi Peredri

В этой статье сравнивается эффективность использования C++/Qt и Java/AWT/Swing для разработки программного обеспечения с пользовательским графическим интерфейсом.

1. Что мы сравниваем?

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

Другие компоненты средств разработки, такие, как библиотеки доступа к базам данных или библиотеки коммуникаций, также должны быть приняты во внимание, но они не оказывают такого влияния на разработку проекта, как библиотеки GUI.

Целью этой статьи является сравнение C++/Qt и Java/AWT/Swing. Чтобы это сделать наиболее точно, мы сначала сравним языки программирования, то есть C++ и Java, а потом две GUI-библиотеки: Qt для C++ и AWT/Swing для Java.

2. Сравнение C++ и Java

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

2.1. Продуктивность программирования

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

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

Для этого язык Java наделен некоторыми дополнительными возможностями. Например, в отличие от C++ (или C), программист не должен в явном виде «освобождать» (возвращать) выделенную память операционной системе. Освобождение неиспользуемой памяти (сборка «мусора») автоматически обеспечивается средой выполнения Java в ущерб производительности и эффективности использования памяти (см. далее). Это освобождает программиста от утомительной задачи по слежению за освобождением памяти – главного источника ошибок в приложениях. Одна эта возможность языка должна значительно увеличить продуктивность программирования в сравнении с C++ (или C).

Однако проведенное исследование показывает, что на практике сборка «мусора» и другие возможности Java не оказывают большого влияния на продуктивность программирования. Одна из классических моделей оценки программного обеспечения CoCoMo, предложенная Barry Boehm, предопределяет стоимость и сроки разработки программного продукта на основе стоимостных коэффициентов, которые учитывают такие факторы, как суммарный опыт программирования разработчика, опыт программирования на заданном языке, желаемая надежность программы и т.д. Boehm пишет, что независимо от уровня используемого языка, начальные трудозатраты всегда высокие. Подобная методика подсчета использовалась в другом исследовании, проведенном C.E.Walston и C.P.Felix, IBM, Метод измерения и оценки программирования (A method of programming measurement and estimation) .

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

Существует более позднее исследование, которое явно включает Java и которое подтверждает эту гипотезу. В Эмпирическом сравнении C, C++, Java, Perl, Python, Rexx и Tcl (An empirical comparison of C, C++, Java, Perl, Python, Rexx, and Tcl) Lutz Prechelt из университета Karlsruhe описывает проведенный им эксперимент, в котором студентам информатики поручили выполнить определенный проект и выбрать для его реализации, руководствуясь личными предпочтениями, один из языков программирования: C, C++ или Java (остальные языки были рассмотрены в другой части исследования). Собранные данные показали почти одинаковые результаты для C++ и Java (C был на третьем месте по многим параметрам). Эти результаты подтверждаются нашим собственным опытом: если программисты вольны в самостоятельном выборе языка программирования (чаще руководствуясь при этом своим опытом), программисты с равным опытом работы (например, измеренным в годах) достигают одной и той же продуктивности. Второй интересный аспект, который бы мы хотели отметить (но который не имеет формального экспериментального подтверждения), заключается в том, что менее опытные разработчики достигают лучших результатов с Java, разработчики со средним опытом разработки достигают одинаковых результатов с обоими языками программирования, опытные разработчики достигают лучших результатов с C++. Эти наблюдения могут быть объяснены тем, что для C++ доступны более совершенные средства разработки; и этот факт тоже должен быть принят во внимание.

Интересный способ определения продуктивности программирования предлагает метод функциональных единиц (Function Point), разработанный Capers Jones. Функциональная единица – это метрика программного обеспечения, которая зависит лишь от его функциональности, а не от конкретной реализации. Эта метрика позволяет использовать в качестве критерия оценки продуктивности программирования число строк кода, необходимых для обеспечения одной функциональной единицы, в свою очередь, уровень языка определяется числом функциональных единиц, которые могут быть созданы за определенное время. Интересно, что обе величины: число строк кода на единицу функциональности и уровень языка одинаковы для обоих языков (уровень языка: C++ и Java – 6, C – 3.5, Tcl – 5; число строк кода на единицу функциональности: C++ и Java – 53, C – 91, Tcl – 64).

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

2.2. Производительность работы приложений

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

И снова Prechelt предоставляет интересные сведения. Объем предлагаемой им информации огромен, но в конечном итоге он приходит к заключению, что «Java-программы выполняются по крайней мере в 1.22 раза медленнее C/C++ программ». Заметьте, что он сказал по крайней мере; средняя же скорость работы Java-программ гораздо меньше. Наш собственный опыт показывает, что Java-программы выполняются приблизительно в 2-3 раза медленнее своих C/C++ аналогов. На задачах, ориентированных на интенсивное использование процессора, Java-программы проигрывают еще сильнее.

В случае программ с пользовательским графическим интерфейсом увеличение времени отклика интерфейса является более критичным, чем низкая производительность программы. Проведенные исследования показывают, что пользователи более терпимы к задачам, выполняющимся в течение двух или трех минут, чем к программам, которые не реагируют мгновенно на их воздействия, например, на нажатия кнопок. Эти исследования показывают, что если время отклика программы больше, чем 0,7 секунды, пользователи считают ее медленной. Мы вернемся к этой проблеме, когда будем сравнивать пользовательский графический интерфейс в программах Java и C++.

Объяснение того, почему Java-программы медленнее C++ программ, заключается в следующем. C++ программы компилируются компилятором C++ в двоичный формат, который затем исполняется непосредственно процессором; таким образом, выполнение программы осуществляется аппаратными средствами. (Это несколько упрощенно, так как большинство современных процессоров выполняют микрокод, но это не принципиально при обсуждении данного вопроса.) С другой стороны, компилятор Java компилирует исходный код в «байт-код», который непосредственно исполняется не процессором, а с помощью другого программного обеспечения, виртуальной машины Java (Java Virtual Machine, JVM). В свою очередь, JVM исполняется процессором. Таким образом, выполнение байт-кода Java-программ осуществляется не быстрыми аппаратными средствами, а с помощью более медленной программной эмуляции.

Для повышения производительности работы Java-программ были разработаны «Just in Time» (JIT) компиляторы, но универсального решения этой проблемы не существует.

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

Но разве использование платформенно-независимого байт-кода является верным подходом в создании кросс-платформенных приложений? С хорошим кросс-платформенным инструментарием, наподобие Qt, и хорошими компиляторами для различных платформ программисты могут достичь почти той же цели компиляцией своего исходного кода один раз для каждой из платформ: «написанный однажды код компилируется везде». Можно возразить, что для этого разработчикам потребуется доступ ко всем поддерживаемым платформам, в то время, как с Java, теоретически, разработчикам необходим доступ только к одной из платформ, имеющей средства разработки для Java и JVM. На практике же ни один из ответственных производителей программного обеспечения не будет сертифицировать свои программные продукты для платформ без предварительного их тестирования, поэтому в любом случае производителям будет необходим доступ ко всем поддерживаемым платформам.

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

2.3. Эффективность использования памяти

Java и C++ используют различные подходы в управлении памятью. В C++ управление памятью полностью осуществляется программистом, т.е. по мере необходимости распределение и освобождение памяти должно выполняться программистом. Если программист забывает освободить ранее полученную память, возникает «утечка памяти». Если во время работы приложения произойдет лишь одна такая утечка, проблем не возникнет, так как после завершения работы приложения операционная система освободит всю ранее использованную им память. Но если утечки памяти будут происходить постоянно (например, если пользователь будет периодически выполнять определенные действия), использование памяти приложением будет расти вплоть до полного ее расхода с последующим возможным отказом системы.

Java обеспечивает автоматическое освобождение неиспользуемой памяти. Наряду с распределением памяти программистом JVM ведет учет всех используемых блоков памяти и указателей на них. Если блок памяти больше не используется, он может быть освобожден. Это обеспечивает процесс, который называется «сборкой мусора». Он периодически вызывается JVM, проверяет все используемые блоки памяти и освобождает те из них, на которые отсутствуют указатели.

Сборка мусора очень удобна, но за ее использование приходится расплачиваться большим потреблением памяти и низкой производительностью… Программисты C++ могут (и должны) освобождать блоки памяти сразу после того, как они перестали быть нужны. С Java блоки не освобождаются до очередного вызова сборщика мусора, периодичность работы которого зависит от использумой реализации JVM. Prechtelt предоставляет цифровые данные, утверждая, что в среднем, (…) и с вероятностью 80% Java-программы используют на 32 MB (или 297%) памяти больше, чем C/C++ программы (…). Вдобавок к большому расходу памяти процесс сборки мусора требует дополнительной процессорной мощности, которая в результате становится недоступной приложению, и это приводит к замедлению его работы. Поэтому периодическая работа сборщика мусора может приводить к «замораживанию» Java-программы на несколько секунд. Лучшие реализации JVM минимизируют такие замораживания, но не устраняют их полностью.

При работе с внешними программами и устройствами, например, во время ввода/вывода или при взаимодействии с базой данных, желательно закрыть файл или соединение с базой данных сразу же после того, как они перестали быть нужны. Благодаря деструкторам C++ это происходит сразу после вызова delete. В Java закрытие произойдет лишь во время следующего цикла работы сборщика мусора. В лучшем случае это может привести к излишней блокировке ресурсов, в худшем – к нарушению целостности открытых ресурсов.

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

Главная причина, по которой сборка мусора является более дорогостоящей, чем непосредственное управление памятью программистом, – это утрата информации. В C++ программе программист знает и местонахождение своих блоков памяти (сохраняя указатели на них), и когда они перестанут быть ему нужными. В Java-программе последняя информация недоступна для JVM (даже если она известна программисту), поэтому JVM должна перебирать все блоки на предмет отсутствующих указателей. Для того, чтобы вызвать сборку мусора вручную, Java-программист может удалить все указатели на больше ненужные ему блоки памяти. Но со стороны программиста это потребует больше усилий, чем непосредственное управление памятью в C++; и, тем не менее, во время сборки мусора JVM все равно придется проверить все блоки памяти, чтобы освободить неиспользуемые.

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

Так как управление памятью в C и C++ обременительно для программиста, созданное с помощью этих языков программное обеспечение обвиняется в нестабильной работе и подверженности ошибкам. Хотя некорректная работа с памятью в C и C++ может привести к более критичным ошибкам (обычно приводящим к аварийному завершению программы), хорошие знания, инструментарий и опыт могут значительно уменьшить связанный с этим риск. Изучению управления памятью должно уделяться достаточно внимания. Также существует большое число коммерческих и свободных инструментов, позволяющих программистам обеспечить отсутствие в программах ошибок при работе с памятью; например, Parasoft Insure++, Rational Purify и Electric Fence. Гибкая система управления памятью в C++ делает возможным создавать адаптированные для любого типа приложений профилировщики памяти.

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

2.4. Доступные библиотеки и инструментарий

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

Однако это преимущество Java является также ее недостатком. Разобраться в огромном API программисту становится все сложнее. Можете быть наверняка уверены, что для любой задачи всегда найдется уже готовое решение или, по крайней мере, решение, облегчающее выполнение этой задачи. Но найти пригодный для этого пакет и класс становится все труднее. Также с увеличением числа пакетов стремительно растет размер Java-платформы. В результате стали возникать ее «урезанные» версии, утратившие преимущества готовых решений. Таким образом, размер Java-платформы делает практически невозможным создание Java-систем небольшими производителями независимо от создателя Java Sun Microsystems, что ослабляет конкуренцию.

Если преимущества Java заключаются в доступных библиотеках, то явные преимущества C++ – в имеющихся средствах разработки. За все время существования семейства языков C и C++ было создано огромное количество самых разнообразных средств разработки, включая инструменты для дизайна, отладки и профилирования. Имеющиеся средства разработки для Java часто уступают по возможностям своим C++ -аналогам. Это справедливо даже для инструментов от одного производителя; например, сравните Java и C/C++ -версии профилировщика Rational Quantify.

Самым важным инструментом для любого разработчика, использующего компилируемые языки, является компилятор. Основным достоинством компиляторов C++ является скорость работы. Для обеспечения кросс-платформенности своих компиляторов (и других средств разработки) производители Java-инструментов часто сами используют Java, со всеми вытекающими отсюда проблемами производительности и эффективности использования памяти. Иногда встречаются Java-компиляторы, написанные на C/C++ (например, IBM Jikes), но это редкость.

3. Сравнение AWT/Swing и Qt

До сих пор мы сравнивали лишь языки программирования Java и C++. Но, как мы упомянули в начале этой статьи, язык программирования является лишь одним из аспектов, принимаемых во внимание при разработке GUI. Теперь мы сравним пакеты для разработки GUI, которые поставляются вместе с Java, т.е. AWT и Swing, и кросс-платформенный инструментарий Qt от норвежского производителя Trolltech. В сравнении мы ограничились лишь одним инструментарием C++, потому что в отличие от MFC (Microsoft Foundation Classes) и других подобных библиотек, Qt поддерживает все 32-битные Windows-платформы (кроме NT 3.5x), большинство разновидностей Unix, включая Linux, Solaris, AIX и Mac OS X, и встраиваемые платформы. Это позволяет максимально близко сопоставить платформы Java/AWT/Swing и C++/Qt.

3.1. Описание AWT, Swing и Qt

Инструментарий AWT (Abstract Windowing Toolkit) начал поставляться с самой первой версией Java. Он использует родные для платформ компоненты GUI (т.е. Win32 API для Windows и библиотеку Motif для Unix), обеспечивая таким образом переносную обертку. Это значит, что внешний вид и поведение AWT-программ будет отличаться на различных платформах, потому что именно они занимаются отрисовкой и управлением компонентов GUI. Это противоречит кросс-платформенной философии Java и может быть объяснено тем, что первая версия AWT была разработана за четырнадцать дней.

По этой и другим причинам AWT был дополнен инструментарием Swing. Swing использует AWT (и, следовательно, низкоуровневые библиотеки) только лишь для базовых операций: создания прямоугольных окон, управления событиями и отрисовки графических примитивов. Всем остальным, включая отрисовку компонентов GUI, занимается Swing. Это решает проблему отличающегося внешнего вида и поведения приложений на различных платформах. Но из-за реализации Swing-инструментария средствами Java его производительность оставляет желать лучшего. В результате Swing-программы медлительны не только во время интенсивных вычислений, но и при отрисовке элементов пользовательского интерфейса. Как уже говорилось, ничто не вызывает у пользователей такого раздражения, как большое время отклика интерфейса программ. Странно наблюдать за медлительностью перерисовки Swing -кнопки на современном оборудовании. Хотя с ростом производительности оборудования эта ситуация будет постепенно улучшаться, сложным пользовательским интерфейсам, созданным с помощью Swing, всегда будет свойственна медлительность.

При разработке инструментария Qt был использован тот же самый подход: низкоуровневые библиотеки используются только лишь для базовых операций, а отрисовкой элементов GUI занимается непосредственно Qt. Благодаря этому инструментарий Qt приобретает все преимущества Swing (например, схожесть поведения и внешнего вида приложений на различных платформах), и не имеет проблем, связанных с низкой производительностью, так как разработан на C++ и откомпилирован в машинный код. Интерфейс, созданный с помощью Qt, отличается быстрой работой, и, благодаря использованию кэширования, может быть быстрее интерфейса, разработанного стандартными средствами. Теоретически, оптимизированная не-Qt программа должна быть быстрее аналогичной Qt-программы; но на практике для оптимизации не-Qt программы потребуется больше усилий и мастерства, чем для создания оптимизированной Qt-программы.

И Qt, и Swing поддерживают технику стилей, которая позволяет программам независимо от платформы использовать один из стилей интерфейса. Это становится возможным благодаря тому, что отрисовкой элементов GUI занимаются непосредственно Qt и Swing. Вместе с Qt поставляются стили, которые эмулируют внешний вид Win32, Motif, MacOS X Aqua (в Macintosh-версии), и даже стиль, эмулирующий внешний вид Swing-программ.

3.2. Парадигмы программирования в Qt и Swing

Несмотря на то, что оценка API в определенной степени является делом личных предпочтений программиста, среди API-интерфейсов можно выделить такие, которые сделают ваш код более простым, кратким, элегантным и читаемым, чем другие. Ниже мы приводим два примера кода: первый с использованием Java/Swing, а второй с использованием C++/Qt, в которых реализуется вставка нескольких элементов в иерархическое дерево. Swing-код:

…
DefaultMutableTreeNode root = new DefaultMutableTreeNode( «Root» );
DefaultMutableTreeNode child1 = new DefaultMutableTreeNode( «Child 1″ );
DefaultMutableTreeNode child2 = new DefaultMutableTreeNode( «Child 2″ );
DefaultTreeModel model = new DefaultTreeModel( root );
JTree tree = new JTree( model );
model.insertNodeInto( child1, root, 0 );
model.insertNodeInto( child2, root, 1 );
…
Этот же код с использованием Qt:

…
QListView* tree = new QListView;
QListViewItem* root = new QListViewItem( tree, «Root» );
QListViewItem* child1 = new QListViewItem( root, «Child 1″ );
QListViewItem* child2 = new QListViewItem( root, «Child 2″ );
…
Как видите, Swing использует архитектуру Model-View-Controller (MVC), в то время как Qt ее поддерживает, но не навязывает использовать. Поэтому Qt-код более интуитивен. К такому же результату приводит сравнение кода для создания заполненной таблицы или других сложных компонентов GUI.

Вторым интересным моментом является то, как различные инструментарии связывают воздействие пользователя (например, выбор элемента в выше созданном дереве) с определенной функциональностью (вызовом функции или метода). Синтаксически в Java/Swing и C++/Qt это выглядит по-разному, но основной принцип общий. Трудно сказать, какой код является более ясным и элегантным, Swing-код:

…
tree.addTreeSelectionListener( handler );
…
или Qt-код:

…
connect( tree, SIGNAL( itemSelected( QListViewItem* ) ),
handler, SLOT( handlerMethod( QListViewItem* ) ) );
…
С одной стороны, Swing-код выглядит проще, а с другой – Qt-код более гибок. Qt позволяет программисту использовать для управляющей функции любое имя, в то время, как Swing обязывает использовать в качестве имени valueChanged() (вот почему в приведенном выше Swing-примере оно не было указано явно). Также Qt позволяет связывать событие (сигнал в терминологии Qt) с любым числом управляющих функций (слотов).

Таким образом, и Java/AWT/Swing, и C++/Qt одинаково хорошо подходят для разработки сложного пользовательского интерфейса. Главным недостатком Swing-интерфейса является низкая производительность Java.

4. Заключение

Мы сравнили две платформы: Java/AWT/Swing и C++/Qt, оценив их пригодность для эффективной разработки высокопроизводительных приложений с пользовательским графическим интерфейсом. В то время, как Java-платформа обеспечивает разработчикам сравнимую продуктивность программирования, платформа C++/Qt обеспечивает приложениям лучшую производительность и эффективность использования памяти. Также C++ выигрывает за счет более лучших средств разработки.

Что касается сравнения GUI-библиотек, Swing и Qt, то видно, что более худшая производительность Java-программ делает платформу Java/Swing менее подходящей для разработки GUI-приложений, даже при сравнимом опыте программирования. В отличие от Swing, Qt не навязывает программисту парадигму программирования Model-View-Controller, поэтому в результате Qt-программы получаются более краткими.

Независимое научное исследование и полученный практический опыт эксплуатации показывают, что предпочитаемость использования Java во многих случаях чаще всего неоправданна, а комбинация C++/Qt является более лучшей. Главными причинами этого являются более низкие производительность и эффективность использования памяти в Java (особенно при использовании инструментария Swing) при такой же обеспечиваемой продуктивности программирования. Во многих выполненных нами проектах начинающие программисты осваивали быстрее Java, более опытные и профессиональные разработчики (занимающиеся проектированием приложений и реализацией критичных участков программ) достигали быстрее лучших результатов с помощью C++.

Java/Swing может подойти для разработки некоторых программ, особенно если они без GUI-интерфейса или с ограниченной GUI-функциональностью. В целом, C++/Qt является более лучшим решением, в особенности для разработки GUI-приложений.

что-то вордпресс криво парсит теги объекта, посему, ссылка http://www.ted.com/talks/view/id/66

добавил с ютуба

Нумерация версий ПО

«Validation» is a fable about the magic of free parking.
Starring TJ Thyne & Vicki Davis.
Writer/Director/Composer – Kurt Kuenne.

Winner – Best Narrative Short, Cleveland Int’l Film Festival, Winner – Jury Award, Gen Art Chicago Film Festival, Winner – Audience Award, Hawaii Int’l Film Festival, Winner – Best Short Comedy, Breckenridge Festival of Film, Winner – Crystal Heart Award, Best Short Film & Audience Award, Heartland Film Festival, Winner – Christopher & Dana Reeve Audience Award, Williamstown Film Festival, Winner – Best Comedy, Dam Short Film Festival, Winner – Best Short Film, Sedona Int’l Film Festival.

Есть фильмы хорошие, а есть плохие… есть интересные и не очень; есть те которые смотришь один раз,  есть те которые хочешь пересмотреть много раз..

А есть те фильмы, о которых много думаешь, и не можешь молчать. Гонсалес Иньярриту талантливый режиссер и его фильмы всегда оставляют после себя след, чего только стоит его фильм «Сука-любовь» (Amores perros), что входит в топ-250 имбд(128 место), который еще многие дни после просмотра не покидает зрителя.  Но сегодня я, наконец-то, посмотрел его другой фильм, который уже давно хотел посмотреть – «21 грамм «. Данная картина на протяжении всего фильма держит зрителя возле себя, заставляет чувствовать всё что переживают герои. Да что там на протяжении всего фильма, даже после, ходишь и думаешь, думаешь о всём… 21 грамм – один с тех фильмов которые изменяют нас раз и навсегда, которые невозможно забыть… да что тут говорить, смотрите

How much does guilt weigh?

Говорят, что каждый человек в момент смерти теряет 21 грамм. Столько весит горстка монет в пять центов, плитка шоколада, птица колибри…

«21 грамм» — это история о надежде и человечности, жизнелюбии и выживании. Независимо от того, боитесь вы смерти или нет, она приходит, и в этот момент ваше тело становится на 21 грамм легче. Быть может, это вес человеческой души?

отличный актёрский состав:

В такие картины без таланта не попадешь. Да и награды венецианского кинофестиваля обо всем говорят сами: «Лучший актер» — Шон Пенн; «Лучшая актриса (зрительские симпатии) » — Наоми Уоттс; «Лучший актер (зрительские симпатии) » — Бенисио Дель Торо. Тут и говорить больше ничего не следует, все уже сказано множеством слов до меня.

более подробную информацию можете посмотреть на кинопоиске
http://www.kinopoisk.ru/level/1/film/9393/

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

• стили элемента

1 #ns_tt{
2 position: absolute;
3 border: solid #AAAAAA 1px;
4 background-color: #DDDDDD;
5 font-family: Tahoma, sans-serif;
6 font-size: 11px;
7 line-height: 16px;
8 padding: 2px 5px;
9 overflow: hidden;
10 margin: 25px 0px 0px 5px;
11 }

Создаём js файл.
Вот тут самое интересное.
Создаём переменные отвечающие за левую и верхнюю позицию подсказки:

var l = 0, t = 0

Проверяем браузер. Если это Internet Explorer, то он будет понимать document.all и соответственно у него другие понятия о событиях и значениях которые они возвращают.

var IE = document.all?true:false

При движении мыши запускаем функцию, которую опишем ниже:

document.onmousemove = getMouseXY

Создаём элемент div который у нас будет являться подсказкой:

var ns_tt = document.createElement(«div«)

А эта функция будет изменять положение подсказки относительно положения курсора мыши:

function getMouseXY(e) {
if (IE) {
l = event.clientX + document.body.scrollLeft
t = event.clientY + document.body.scrollTop
}
else {
l = e.pageX
t = e.pageY
}
ns_tt.style.left = l + «px«
ns_tt.style.top = t + «px«
return true
}

Как вы видели мы проверяли наличие браузера IE. Дело в том что IE во-первых: положение курсора мыши понимает из объекта event в частности его значений clientX и clientY; во-вторых: координаты мыши отсчитываются от левого верхнего угла окна браузера, а когда пользователь использует прокрутку то в IE координата смещается, чего нет в других браузерах.

Следующая функция помещает в body нашу подсказку, вставляет текст переданый в качестве параметра и даёт ей уникальное имя, по которой в последствии мы будем её искать для удаления:

function AddTT(tt_text){
document.body.appendChild(ns_tt)
ns_tt.id = «ns_tt«
ns_tt.innerHTML = tt_text
}

Последняя функция удаляет подсказку:

function RemoveTT() {
document.body.removeChild(document.getElementById(«ns_tt«))
}

• весь JavaScript

1 var l = 0, t = 0
2 var IE = document.all?true:false
3 document.onmousemove = getMouseXY
4 var ns_tt = document.createElement(«div«)
5 function getMouseXY(e) {
6 if (IE) {
7 l = event.clientX + document.body.scrollLeft
8 t = event.clientY + document.body.scrollTop
9 }
10 else {
11 l = e.pageX
12 t = e.pageY
13 }
14 ns_tt.style.left = l + «px«
15 ns_tt.style.top = t + «px«
16 return true
17 }
18
19 function AddTT(tt_text){
20 document.body.appendChild(ns_tt)
21 ns_tt.id = «ns_tt«
22 ns_tt.innerHTML = tt_text
23 }
24
25 function RemoveTT() {
26 document.body.removeChild(document.getElementById(«ns_tt«))
27 }

используем всё следующим образом:

<div onmouseover=»AddTT(‘это наша подсказка,<br /> в которой мы можем использовать <b>html</b>’);» onmouseout=»RemoveTT();»>
Текст, картинка, блок, то что требует подсказки </div>

Тестировано в: IE 6, IE 7, Opera 9.02, Firefox 2.0.0.1

первоисточник и пример: http://seleckis.lv/wp-content/uploads/File/scripting/ns_tooltip.html

p.s. а вы знаете, что уже прошла половина лета? (:

Давно я не писал в блог, поэтому решил оставить маленькую заметку
внутри вы прочитаете о гугло Ос, пхп 5.3 и еще некоторых новостях. Вообщем, велком инсайд (:

глобальные новости:
гугл заявил о выпуске своей оси, которая, цитирую:

Она станет логическим продолжением браузера Chrome и попыткой изменить представление о том, какой должна быть операционная система.

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

Для разработчиков приложений платформой будет являться веб. Все существующие веб-приложения будут работать на ОС Google Chrome автоматически, а новые можно будет писать с использованием любой веб-технологии. И, конечно, эти приложения будут работать не только на Google Chrome ОС, но и в любых браузерах стандартных ОС: Windows, Mac и Linux, предоставляя разработчикам самую большую базу пользователей всех платформ.

полный текст новости можно прочесть на их офф блоге:
http://googlerussiablog.blogspot.com/2009/07/google-chrome.html

еще одной интересной новостью стал выход php 5.3 в котором реализовали много того, что должно было выйти в php6

• Обновлены bundled версии sqlite и pcre
• следующие расширения были перемещены в PECL

ext/dbase
ext/fbsql
ext/fdf
ext/ncurses
ext/mhash (слой BC теперь полностью находится в ext/hash)
ext/ming
ext/msql
ext/sybase (более не поддерживается, используйте вместо него sybase_ct)

• Несколько изменен синтакс php.ini для удобства и улучшения его читабельности
• Расширения SPL, PCRE, Reflection теперь включены по умолчанию. Режим FastCGI, к тому же, не может быть отключен
• Добавлены лямбда-функции и замыкания, оператор «jump label», cинтаксисы NOWDOC, HEREDOC, несколько новых констант
• Добавлена поддержка пространств имен, добавлена улучшенная обработка исключений (exceptions linking, exceptions in destructors,
• Улучшена производительность и оптимизировано потребление памяти.
• Появился сборщик мусора
• Улучшена поддержка Windows, в том числе и Windows 7
• Улучшения в расширениях streams, dns api, hash, imap, mbstring, osi8, openssl, pcntl, soap, spl.
• Новые расширения — enchant (проверка орфографии), fileinfo, intl, mysqlnd, phar (архивы php), sqlite3
• Многочисленные изменения и улучшения в функциях PHP, исправления ошибок и многое другое

Вообщем это одно из самых сильных изменений в пхп за последние лет 5, точно.

Более подробно можно почитать на хабре:
http://habrahabr.ru/blogs/php/63926/
+ еще интересно тут:
http://www.slideshare.net/tobias382/new-spl-features-in-php-53

з.ы. мне попалась ссылка на какой-то тест на пхп-разработчика

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

По информации журналов Nature и Wired, легендарный исследовательский центр Bell Labs в скором времени радикальным образом сократит фундаментальные исследования в области материаловедения и физики полупроводников — в тех самых направлениях, что подарили миру такие открытия, как транзистор, лазер и ряд других, за которые 11 учёных центра были удостоены шести Нобелевских премий.

Материнская компания Alcatel-Lucent, переживающая сейчас далеко не лучший свой период, существенно урезает финансирование центра по тем проектам, которые не могут принести ей быструю коммерческую выгоду. Следствием такого положения дел стало сворачивание практически всех фундаментальных исследований, которые велись на базе Bell Labs с 30-х годов прошлого века. Фактически все задействованные в этих проектах сотрудники были вынуждены либо подыскать себе более надёжное место работы за пределами центра, либо перейти в другие его отделы, которые занимаются теми или иными прикладными проектами. После всех кадровых сокращений, растянувшихся на несколько лет, в отделе фундаментальных физических исследований центра в настоящий момент осталось всего четыре человека.

Перепрофилирование научных проектов в русле приоритетных для материнской компании направлений полностью соответствует инновационной модели развития исследований, недавно принятой в Alcatel-Lucent, утверждает представитель этой компании Питер Бенедикт.

Однако инсайдеры рангом пониже не разделяют его уверенность и оптимистичный настрой. Владимир Аксюк, бывший сотрудник Bell Labs, ныне работающий в статусе приглашённого профессора в Национальном институте стандартов и технологий в Гэйзерсбурге, штат Мэриленд считает, что «компания попросту больше не может поддерживать исследовательские проекты. Пройдитесь по центру — и вы увидите совершенно пустые комнаты». «Почти все учёные ушли», — вторит ему Дик Слашер, другой бывший сотрудник Bell Labs, перешедший в Технологический институт в Атланте, штат Джорджия.

Сторонние эксперты также весьма критично отнеслись к известию о сворачивании основного массива фундаментальных исследований в этом крупнейшем центре науки, который более полувека служил ориентиром для учёных со всего мира. Такой шаг они оценили как «недальновидный», который ещё радикальным образом скажется на способности компании Alcatel-Lucent к созданию действительно инновационных разработок.

«Фундаментальная физика чрезвычайно важна для компьютерных технологий, — говорит Майк Лубелл, глава пресс-службы Американского физического общества. — Скажем, к открытию интегральных микросхем подвели бесчисленные маленькие достижения, годами накапливаемые в области физики».

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

Bell Labs (Bell Laboratories, прежние названия — AT&T Bell Laboratories, Bell Telephone Laboratories) — крупный исследовательский центр в области телекоммуникаций, электронных и компьютерных систем. Создан в 1925 как исследовательский центр компании AT&T. В 1995 году Bell Labs выкупила компания Lucent Technologies, которую в 2006 году приобрела французская Alcatel. В настоящее время является исследовательским центром корпорации Alcatel-Lucent.
Среди сотрудников этого известного исследовательского центра — одиннадцать лауреатов Нобелевской премии. За время существования Bell Labs было получено более 27 000 патентов. Из наиболее известных открытий: транзистор (1947), радар, стереозапись, звуковое кино, передача телепрограммы на дальние расстояния, спутники связи и лазеры, солнечные элементы, операционная система Unix, языки программирования Си и С++, интеллектуальная сеть, ИКМ-аппаратура для передачи высококачественных аудио- и видеоданных (1948), сотовая телефония (1971), широкополосная коммутация пакетов и многое другое.

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

Оригинал: http://channel9.msdn.com/posts/mikcher/GPU-Algorithms-Part3/
Видео: mms://mschnlnine.wmod.llnwd.net/a1809/d1/ch9/0/2/3/8/5/4/GPUPart2_s_ch9.wmv

Семен Козлов, разработчик в команде DirectX, во второй части доклада отвечает на вопросы аудитории про вычисления общего назначения на современных видеокартах.

Оригинал: http://channel9.msdn.com/posts/mikcher/GPU-Algoritms-Part2/
Видео: http://mschnlnine.wmod.llnwd.net/a1809/d1/ch9/0/2/3/8/5/4/GPUPart2_s_ch9.wmv