> «Девушка наполовину беременна»? Они либо ловятся, либо не ловятся потому что, покрытие тестами недостаточно.
Есть очень много ошибок, которые практически невозможно покрыть тестами:
— ошибки concurrency
— системные ошибки
— ошибки совместной модификации (concurrent modifications)
— ошибки финализации и освобождения ресурсов (leaks)
— third-party ввиду разных версий библиотек или компонентов системы на local и production
— real-time код
Кроме того есть те вещи, которые принципиально невозможно протестировать автоматически, и можно только наблюдать лишь визуально: правильно ли отображается графический элемент, правильно ли рендерится сцена, не уехал ли лейаут, etc…
Так что не панацея.
> которые про всё это только слышали, но отлично за 10 лет научились конструировать пятиколесные велосипеды и God object классы.
TDD-шники впадают в другую крайность как тотальная декомпозиция кода, которая суть есть не меньшее зло, чем God object. Вместо емкого, но понятного класса создается куча компонентов со слабыми зависимостями. Каждый из компонентов тестируется отдельно своим набором тестов вплоть до теста геттеров и сеттеров. И тем не менее при дальнейшей их компоновке возникают ошибки. В итоге все-равно приходится писать сложный top-level test, который тестирует всю задачу целиком. Усилий в 10 раз больше, кода в 5 раз больше, а результат тот же, что и с God object.
При сложной архитектуре юниты помогают «закрепить» то, что уже работает. Часто бывает так, что при добавлении нового функционала или рефакторинга отваливается то, что уже работало. Особенно при команде из нескольких человек.
> Все что может ломаться — ломается и пишет в логи при запуске сервера.
Это долгий и нудный способ: при каждом изменении запускать сервер и делать деплой (разработчики Java меня поймут). Если какой-то код невозможно запустить без сервера в stand-alone debug режиме, то нужно пересмотреть используемые средства
> Остальное ломается спустя сотни часов тестирования пользователями.
Не все, а только часть. Остальное годами фантомно глючит на продакшне без возможности отловить. Справедливости ради, отмечу, что подобное юнит тестами как правило тоже не ловится ;)
> У меня прямо комплексы насчет этих тестов.
Не стоит. Вы должны понимать, что TDD это такая модная теоретическая концепция, и соответственно:
— далеко не всегда практична
— со временем уйдет или перерастет во что-то другое
Сейчас вы полностью пишите код, а затем его запускаете и отлаживаете. Попробуйте попытаться разбить этот процесс на несколько частей: пишите какую-то часть функционала и отлаживаете ее. Система еще не готова и запустить ее не удастся. Поэтому Вам требуется тест, чтобы прогнать ту часть кода, которую Вы написали. Для этого Вам нужно решить проблему как максимально изолировать тестируемый код от зависимостей.
Пример: вы пишите онлайн игру с GUI (например шахматы). Сначала запрограммируйте общие правила игры: как ходят фигуры, возможность хода, детект мата и шаха. Соответственно тесты для них. Затем напишите игровой движок, который представляет простейший конечный автомат. В тестах к нему забейте различные сценарии игры (партии). Далее по той же схеме нужно написать network layer для передачи ходов с тестами к нему. Затем GUI. Тестами для GUI может быть автоматическое проигрывание партии по заданному сценарию.
Не обязательно для XSS использовать JavaScript. Например, если на сайте разрешена публикация картинки, то взломщик в качестве src может указать что-нибудь вроде «mysite.com/logout» или повесить менее безобидный action. При закрузке страницы браузер попытается загрузить данный image и вызовет action внутри сессии пользователя.
Хорошего способа от этого взлома нет: либо убрать полностью GET с сайта, либо производить жесткую валидацию внутренних URL-ей, либо вообще при отправке сервер пытается загрузить header имиджа.
В современных системах код работает внутри контейнера или фреймворка. Контейнеру необходимо сообщить каким образом интегрировать этот код: нужна ли транзакция, какому полю в базе данных соответствует атрибут, и т.д. То есть помимо кода нужно иметь еще метаданные, описывающие его.
Раньше метаданные описывались отдельно от кода жуткими простынями xml. Было неудобно, но правильно. Затем изобрели XDoclet, который позволял прописывать метаданные прямо в коде при помощи специальных комментариев, а затем генерировал XML. Затем посчитали это полезным и решили ввести эту фишку прямо в язык ввиде аннотаций. Это удобно, но неправильно с точки зрения теории — код становится «завязан» на контейнер/фреймворк.
Я думаю, лучшим способом будет отказаться от конфигурации контейнера аннотациями и делать это на Java при помощи DSL. Например так делает Guice. В Scala есть интересная ORM Squeryl, которая использует схожий подход. Подобная ORM на Java называется QueryDSL.
P.S. Любителям аннотаций задача: есть модель данных и соответвующие ей джава бины. Нужно: с одной стороны замепить эту модель в базу данных, с другой — сделать вебсервис, работающий с ней. Все при условии, что код модели не дублировать. О том как подружить JPA и JAXB читайте на лучших девелоперских форумах… ))
А третьей скорей не будет. Проект мертворожденный, ибо совсем непонятно целевое назначение платформы. JavaFX изначально планировался с прицелом на мобильные платформы на замену J2ME, и теоретически не нуждалась в JRE, но Oracle убила эту инициативу. Теперь JavaFX рассматривается исключительно в контексте десктопов как замена устаревшему Swing-у. Но кто и для чего реально будет его использовать?
Никто не будет переписывать старые апликации, они так и будут выходить на Swing.
Новые проекты будут скорей всего ориентироваться на веб фреймворки типа GWT, Vaadin, Eclipse RAP.
На крайний случай как чисто десктопная альтернатива годен SWT.
Игры будут писать однозначно при помощи веб технологий HTML/Canvas, SVG, WebGL или нативных библиотек для каждой платформы.
JavaFX не кроссплатформенный, и с каждым разом становится все меньше платформ, которые поддерживают не только JavaFX, но и вообще Java. Производители браузеров отказываются от плагинов в пользу стандартов.
То есть все конкурентные ниши уже забиты. Проскакивало где-то сообщение, что к 2014 году планируется, чтобы JavaFX приложение компилировалось в Html5/Canvas backend, тем самым обеспечивая кросс-платформенность. Но мы-то с вами понимаем, что это все из области фантастики…
Теперь уже с сожалением можно сказать, что десктопная война проиграна Java окончательно, и все попытки выправить ситуацию тщетны.
У нас серьезный проект написан на разрекламированном когда-то JavaFX 1.x. Внезапно Oracle объявила, что больше не будет поддерживать JavaFX Script и предложила переписать все на Java и JavaFX 2.0, не предлагая абсолютно никаких средств для миграции. Итак, что мы имеем на данный момент:
JavaFX 1.x:
— официально еще поддерживается до конца 2012, но сайт для загрузки ВНЕЗАПНО отключили под новый год. Пришлось срочно мигрировать все локально.
— также внезапно в начале года истекли сертификаты, которым был подписаны jar-ы
— поддержкой и сборкой занимается волонтер на форуме, один из бывших разработчиков
— JFXtras и все няшные виджеты для 1.x были ВНЕЗАПНО куда-то сметены нахрен
JavaFX 2.0:
— до сих пор нет версий под Linux и Mac (про мобильные платформы я тихо молчу, от них Oracle официально отказалась, хотя изначально JavaFX была с прикидом именно на них). И это несмотря на то, что реально JavaFX 1.x уже не поддерживается. Так что мигрировать пока не на что.
— до сих пор API окончательно не утвержден
— тупо тормозит (поскроллируйте список), несмотря на все супер-пупер акселерации
— вместо обещанного «plugin as simple jar» просит установиться на комп пользователя как add-on
— нет НИКАКИХ средств миграции с JavaFX 1.x, кроме как перелопачивать весь код ручками с JavaFX Script на Java
— всерьез использует 1.5 человек
Спасибо, Oracle, за experience, но что-то внутри мне показывает, что дальнейшую стратегию строить на JavaFX неоправданно рисковано, особенно на фоне всеобщего отказа от плагинной архитектуры…
Кроме того, схожую функциональность можно достичь при помощи GWT+SVG+SmartGWT/ExtGWT/Qooxdoo/etc, и кроссплатформенность идет в подарок.
P.S. основные fails JavaFX 1.x:
— левый не-Java язык
— API радикально менялся от версии к версии
— нет интеграции со Swing приложением
— обещали hardware acceleration, даже таскали с собой .dll, но так и не включили
Интересно услышать от автора подобное сравнение с Vala: live.gnome.org/Vala
— переносимость (в рамках gcc)
— компиляция в native (посредством gcc)
— полная интеграция с существующими библиотеками на C (для этого собственно и разработан)
— С# подобный синтаксис и основные концепции
— вместо сборщика мусора и деструкторов выбран усредненный вариант — счетчик ссылок
— компилируется в JavaScript (пока экспериментально)
(Лирическое отступление) Кстати, в Java именно с этим проблемы. Спецификацией четко не определено, что должен возвращать метод
List getSomeList() {
return someList;
}
— ссылку на someList (чаще всего так и делают)
— unmodifiable wrapper для someList
— копию someList
При отсутствии в Java явных ссылок большинство кодеров не видят и не понимают различий (какая ссылка? мне же вернули сам объект!). А потом вылезают трудно отловимые ошибки с concurrent modification и immutability.
Вы будете удивлены, но большинство полезных концепций реализовано в Java в том или ином виде.
> Посылаем, а не вызываем, сообщения, а не методы
В Java есть класс Proxy, позволяющий генерить обертки для объектов. Кроме того, концепция давно знакома любителям AOP и Spring. Посылка же сообщений чаще всего предполагает именно асинхронный обмен данными, что в Java достигается помощи популярной ныне модели Actors. В данном же случае эта операция имеет свойства именно вызова функции (один тред, стек, блокирующий вызов). Так что можно сильно спорить по поводу корректности терминологии.
> Серьезный шок: любой может испортить мой класс, а не только я
Производные от Java языки типа Groovy, Xtend, Kotlin имеют похожую концепцию расширений (class-extensions). Причем сам класс никак не «портится», это только алиас функции, которая работает над классом в текущем namespace.
> Совсем шокирующее: неинициализированные ссылки не портят почти ничего
Оч. и оч. спорное «улучшение». Это нормально для «скриптовых» языков с нестрогим контролем типов, типа Groovy. В производных языках (Scala, Kotlin, Fantom) взяли концепцию nullable types от C#. Автоматический контроль null програмистам Java должен быть знаком от J2EE/EL и JavaFX Script.
Вот что действительно шокирует, так это синтаксис Objective-C, непохожий ни на один из привычных языков. Но это дело привычки.
Очередной ответ на моральное устаревание Java. Введены многие модные фичи из большинства подобных языков, особенно C# и Gosu (автор упоминает оба). Посему язык не стоит воспринимать как какой-то жутко инновационный прорыв, скорей как некий рефакторинг джавы, которых, в свою очередь, уже over 9000: Groovy++, Gosu, XTend, Fantom, Ceylon, Java8, etc… Тем не менее многие вещи очень радуют. Так что если общественность поддержит, язык найдет свою нишу. Думаю, привычность, простота в использовании, и поддержка коммерческой компанией сделает его серьезным конкуретном Scala.
Спасибо за ссылку.
Хороший дизайн всегда идет в ущерб памяти и производительности. Благо на данный момент это дешевые ресурсы: память стоит копейки по сравнению с разработкой высого оптимизированного кода. Другое дело десктопы и устройства с ограниченной памятью типа смартфонов и планшетников… Видимо поэтому java заняла прочное место на рынке серверов и совсем угасла в десктопной среде.
Правительство закручивает гайки, затыкает рты, творит беспредел? Нахуй такое правительство!
Надеюсь предвыборная пропаганда и агитация еще не преследуется по закону...? ))
Насколько я понял, сам проект называется XText — это конфигурируемый кросс-компилятор в Java, для которого описывается грамматика. Огромнейший плюс XText в том, что IDE понимает описанную грамматику «из коробки», т.е. не надо создавать своего плагина для синтаксиса. При помощи него можно описать практически любой язык или DSL. В частности XTend — это надстройка над Java, выполненная на XText. Своего рода «сахарница», в который добавили некоторые вещи типа closures и интегрировали нативно некоторые паттерны (в основном используемые в EMF типа Extender). Но позиционировать себя как отдельный язык ему еще рановато, так как изначальным концептом все-равно является Java, отсутвтвует четкая парадигма. Это скорей фреймворк. Хотя если в синтаксис добавят основные паттерны, возможно, будет очень полезным.
Вся Испания качает фильмы по инету, а это поддерживается Телефонной компанией, так как подстегивает основной спрос на adsl. Никто этому не препятствует, даже судьи качают. К тому же испанские фильмы трудно заставить смотреть даже за деньги ;)
Тем не менее решение судьи более странно. Во-первых, идет речь о коммерческой выгоде от торговли чужим контентом. Размер ущерба действительно определить невозможно (а денежная заинтересованность сторон — единственный вопрос, решаемый в испанских судах). То есть налицо воровство и осуждение никто не отменял. Поэтому по крайней мере осужденную сторону должны были обязать выплатить заявителю полную сумму дохода, произведенного с продажи пиратских дисков. Плюс возможно штрафы за нелегальную деятельность, и расходы на суд, и адвокатов обеих сторон. Другое дело, что заявленные миллионы евро «потерянной прибыли» не были признаны судом, из-за чего и разгорелся весь сыр-бор.
И все-таки существуют организации типа SGAE, нечно наподобии RIAA, следящие за соблюдением авторского права. Насколько я знаю, были прецеденты, когда оштрафовывали спортзалы, где звучала копирастная музыка без соответствующей лицензии.
Совершенно верно. Выброс непроверяемого исключения говорит о некорректной работе метода, либо некорректном его вызове (недопустимые параметры). И это является ошибкой программы, а не исключительной ситуацией, и решается элементарным тестированием.
Еще есть такая штука как контрактное программирование (http://code.google.com/p/cofoja/). Оно позволяет жестче контролировать корректность вызовов методов и обнаруживать ошибки на ранних стадиях. Каждый метод содержит дескриптор, где указываются ожидаемые значения аргументов и результатов. Там же указываются ВСЕ ожидаемые исключения от метода, как checked, так и unchecked.
Кстати, в javadoc для java api также как правило указываются все unchecked exceptions, которые может выдать метод.
Немного не в тему, может кто сталкивался, какое у Hetzner helpdesk время ответа на просьбу о перезагрузке машины? В нашем текущем хостинге это заняло 1 час 40 минут, чтобы просто перезагрузить тачку — ни в какие ворота не лезет.
Вспомните другой похожий проект от Google — язык Go… Вообще, тенденция Google — громко анонсировать стартап, а затем посмотреть что из него получится, и потихоньку его прикрыть, если результаты неудовлетворительные. Так что не стоит торопиться.
Основная заслуга Java не в языке, а в том, что к ней написаны тонны спецификаций, фреймворков, библиотек, тулзов и т.д. VM работают под любой архитектурой. Кроме того огромное число программеров знает Java и не захотят пересаживаться на другой велосипед. Поэтому потеснить ее с рынка серверов будет сложно.
А вот на десктопе за 15 лет разработок ничего дельного так и не смогли придумать. Самым верным бы было следовать пути Java и завести в браузере универсальную VM, таким образом не привязывая программиста а конкретному языку.
Ну, начинем с того, что Дензел и Бентли — не испанские фамилии. Сеть сделали эти 2 _американца_ по принципу и подобию ФБ. Затем под шумок венчурных инвестиций продались Телефонике, славившейся на весь мир в безполезной трате больших денег (напр. в 2002 купившей Lycos за 11 миллиардов и слившей под ноль).
Сеть действительно приятная, что неудивительно при наличии двух американцев, ибо все, что делают испанцы в области IT — УГ. Однако как уже было упомянуто, основная ценность любой соцсети — количество людей. Tuenti среди испанцев не пользуется даже десятой долей популярности, нежели FB. Да и сама идея не просматривается четко — национальная соцсеть? элитная соцсеть? соцсеть определенной возрастной категории??? Куда она будет расти — тоже не понятно. С телефониковским баблом — в Латинскую Америку. И дальше что? Продаваться ФБ? Словом, очередной пузырь?
Включим паранойю: возможно создание биткоина — спланированная этими самыми ребятами из WallStreet провокация. И если бы они действительно беспокоились за свое благосостояние, то в ход бы пошли другие силы и средства. А так биткоин похоже никто не принимает всерьез.
Есть очень много ошибок, которые практически невозможно покрыть тестами:
— ошибки concurrency
— системные ошибки
— ошибки совместной модификации (concurrent modifications)
— ошибки финализации и освобождения ресурсов (leaks)
— third-party ввиду разных версий библиотек или компонентов системы на local и production
— real-time код
Кроме того есть те вещи, которые принципиально невозможно протестировать автоматически, и можно только наблюдать лишь визуально: правильно ли отображается графический элемент, правильно ли рендерится сцена, не уехал ли лейаут, etc…
Так что не панацея.
> которые про всё это только слышали, но отлично за 10 лет научились конструировать пятиколесные велосипеды и God object классы.
TDD-шники впадают в другую крайность как тотальная декомпозиция кода, которая суть есть не меньшее зло, чем God object. Вместо емкого, но понятного класса создается куча компонентов со слабыми зависимостями. Каждый из компонентов тестируется отдельно своим набором тестов вплоть до теста геттеров и сеттеров. И тем не менее при дальнейшей их компоновке возникают ошибки. В итоге все-равно приходится писать сложный top-level test, который тестирует всю задачу целиком. Усилий в 10 раз больше, кода в 5 раз больше, а результат тот же, что и с God object.
> Все что может ломаться — ломается и пишет в логи при запуске сервера.
Это долгий и нудный способ: при каждом изменении запускать сервер и делать деплой (разработчики Java меня поймут). Если какой-то код невозможно запустить без сервера в stand-alone debug режиме, то нужно пересмотреть используемые средства
> Остальное ломается спустя сотни часов тестирования пользователями.
Не все, а только часть. Остальное годами фантомно глючит на продакшне без возможности отловить. Справедливости ради, отмечу, что подобное юнит тестами как правило тоже не ловится ;)
> У меня прямо комплексы насчет этих тестов.
Не стоит. Вы должны понимать, что TDD это такая модная теоретическая концепция, и соответственно:
— далеко не всегда практична
— со временем уйдет или перерастет во что-то другое
Пример: вы пишите онлайн игру с GUI (например шахматы). Сначала запрограммируйте общие правила игры: как ходят фигуры, возможность хода, детект мата и шаха. Соответственно тесты для них. Затем напишите игровой движок, который представляет простейший конечный автомат. В тестах к нему забейте различные сценарии игры (партии). Далее по той же схеме нужно написать network layer для передачи ходов с тестами к нему. Затем GUI. Тестами для GUI может быть автоматическое проигрывание партии по заданному сценарию.
Хорошего способа от этого взлома нет: либо убрать полностью GET с сайта, либо производить жесткую валидацию внутренних URL-ей, либо вообще при отправке сервер пытается загрузить header имиджа.
Раньше метаданные описывались отдельно от кода жуткими простынями xml. Было неудобно, но правильно. Затем изобрели XDoclet, который позволял прописывать метаданные прямо в коде при помощи специальных комментариев, а затем генерировал XML. Затем посчитали это полезным и решили ввести эту фишку прямо в язык ввиде аннотаций. Это удобно, но неправильно с точки зрения теории — код становится «завязан» на контейнер/фреймворк.
Я думаю, лучшим способом будет отказаться от конфигурации контейнера аннотациями и делать это на Java при помощи DSL. Например так делает Guice. В Scala есть интересная ORM Squeryl, которая использует схожий подход. Подобная ORM на Java называется QueryDSL.
P.S. Любителям аннотаций задача: есть модель данных и соответвующие ей джава бины. Нужно: с одной стороны замепить эту модель в базу данных, с другой — сделать вебсервис, работающий с ней. Все при условии, что код модели не дублировать. О том как подружить JPA и JAXB читайте на лучших девелоперских форумах… ))
Никто не будет переписывать старые апликации, они так и будут выходить на Swing.
Новые проекты будут скорей всего ориентироваться на веб фреймворки типа GWT, Vaadin, Eclipse RAP.
На крайний случай как чисто десктопная альтернатива годен SWT.
Игры будут писать однозначно при помощи веб технологий HTML/Canvas, SVG, WebGL или нативных библиотек для каждой платформы.
JavaFX не кроссплатформенный, и с каждым разом становится все меньше платформ, которые поддерживают не только JavaFX, но и вообще Java. Производители браузеров отказываются от плагинов в пользу стандартов.
То есть все конкурентные ниши уже забиты. Проскакивало где-то сообщение, что к 2014 году планируется, чтобы JavaFX приложение компилировалось в Html5/Canvas backend, тем самым обеспечивая кросс-платформенность. Но мы-то с вами понимаем, что это все из области фантастики…
Теперь уже с сожалением можно сказать, что десктопная война проиграна Java окончательно, и все попытки выправить ситуацию тщетны.
JavaFX 1.x:
— официально еще поддерживается до конца 2012, но сайт для загрузки ВНЕЗАПНО отключили под новый год. Пришлось срочно мигрировать все локально.
— также внезапно в начале года истекли сертификаты, которым был подписаны jar-ы
— поддержкой и сборкой занимается волонтер на форуме, один из бывших разработчиков
— JFXtras и все няшные виджеты для 1.x были ВНЕЗАПНО куда-то сметены нахрен
JavaFX 2.0:
— до сих пор нет версий под Linux и Mac (про мобильные платформы я тихо молчу, от них Oracle официально отказалась, хотя изначально JavaFX была с прикидом именно на них). И это несмотря на то, что реально JavaFX 1.x уже не поддерживается. Так что мигрировать пока не на что.
— до сих пор API окончательно не утвержден
— тупо тормозит (поскроллируйте список), несмотря на все супер-пупер акселерации
— вместо обещанного «plugin as simple jar» просит установиться на комп пользователя как add-on
— нет НИКАКИХ средств миграции с JavaFX 1.x, кроме как перелопачивать весь код ручками с JavaFX Script на Java
— всерьез использует 1.5 человек
Спасибо, Oracle, за experience, но что-то внутри мне показывает, что дальнейшую стратегию строить на JavaFX неоправданно рисковано, особенно на фоне всеобщего отказа от плагинной архитектуры…
Кроме того, схожую функциональность можно достичь при помощи GWT+SVG+SmartGWT/ExtGWT/Qooxdoo/etc, и кроссплатформенность идет в подарок.
P.S. основные fails JavaFX 1.x:
— левый не-Java язык
— API радикально менялся от версии к версии
— нет интеграции со Swing приложением
— обещали hardware acceleration, даже таскали с собой .dll, но так и не включили
— переносимость (в рамках gcc)
— компиляция в native (посредством gcc)
— полная интеграция с существующими библиотеками на C (для этого собственно и разработан)
— С# подобный синтаксис и основные концепции
— вместо сборщика мусора и деструкторов выбран усредненный вариант — счетчик ссылок
— компилируется в JavaScript (пока экспериментально)
— ссылку на someList (чаще всего так и делают)
— unmodifiable wrapper для someList
— копию someList
При отсутствии в Java явных ссылок большинство кодеров не видят и не понимают различий (какая ссылка? мне же вернули сам объект!). А потом вылезают трудно отловимые ошибки с concurrent modification и immutability.
> Посылаем, а не вызываем, сообщения, а не методы
В Java есть класс Proxy, позволяющий генерить обертки для объектов. Кроме того, концепция давно знакома любителям AOP и Spring. Посылка же сообщений чаще всего предполагает именно асинхронный обмен данными, что в Java достигается помощи популярной ныне модели Actors. В данном же случае эта операция имеет свойства именно вызова функции (один тред, стек, блокирующий вызов). Так что можно сильно спорить по поводу корректности терминологии.
> Серьезный шок: любой может испортить мой класс, а не только я
Производные от Java языки типа Groovy, Xtend, Kotlin имеют похожую концепцию расширений (class-extensions). Причем сам класс никак не «портится», это только алиас функции, которая работает над классом в текущем namespace.
> Совсем шокирующее: неинициализированные ссылки не портят почти ничего
Оч. и оч. спорное «улучшение». Это нормально для «скриптовых» языков с нестрогим контролем типов, типа Groovy. В производных языках (Scala, Kotlin, Fantom) взяли концепцию nullable types от C#. Автоматический контроль null програмистам Java должен быть знаком от J2EE/EL и JavaFX Script.
Вот что действительно шокирует, так это синтаксис Objective-C, непохожий ни на один из привычных языков. Но это дело привычки.
Хороший дизайн всегда идет в ущерб памяти и производительности. Благо на данный момент это дешевые ресурсы: память стоит копейки по сравнению с разработкой высого оптимизированного кода. Другое дело десктопы и устройства с ограниченной памятью типа смартфонов и планшетников… Видимо поэтому java заняла прочное место на рынке серверов и совсем угасла в десктопной среде.
Надеюсь предвыборная пропаганда и агитация еще не преследуется по закону...? ))
Тем не менее решение судьи более странно. Во-первых, идет речь о коммерческой выгоде от торговли чужим контентом. Размер ущерба действительно определить невозможно (а денежная заинтересованность сторон — единственный вопрос, решаемый в испанских судах). То есть налицо воровство и осуждение никто не отменял. Поэтому по крайней мере осужденную сторону должны были обязать выплатить заявителю полную сумму дохода, произведенного с продажи пиратских дисков. Плюс возможно штрафы за нелегальную деятельность, и расходы на суд, и адвокатов обеих сторон. Другое дело, что заявленные миллионы евро «потерянной прибыли» не были признаны судом, из-за чего и разгорелся весь сыр-бор.
И все-таки существуют организации типа SGAE, нечно наподобии RIAA, следящие за соблюдением авторского права. Насколько я знаю, были прецеденты, когда оштрафовывали спортзалы, где звучала копирастная музыка без соответствующей лицензии.
Еще есть такая штука как контрактное программирование (http://code.google.com/p/cofoja/). Оно позволяет жестче контролировать корректность вызовов методов и обнаруживать ошибки на ранних стадиях. Каждый метод содержит дескриптор, где указываются ожидаемые значения аргументов и результатов. Там же указываются ВСЕ ожидаемые исключения от метода, как checked, так и unchecked.
Кстати, в javadoc для java api также как правило указываются все unchecked exceptions, которые может выдать метод.
Основная заслуга Java не в языке, а в том, что к ней написаны тонны спецификаций, фреймворков, библиотек, тулзов и т.д. VM работают под любой архитектурой. Кроме того огромное число программеров знает Java и не захотят пересаживаться на другой велосипед. Поэтому потеснить ее с рынка серверов будет сложно.
А вот на десктопе за 15 лет разработок ничего дельного так и не смогли придумать. Самым верным бы было следовать пути Java и завести в браузере универсальную VM, таким образом не привязывая программиста а конкретному языку.
Сеть действительно приятная, что неудивительно при наличии двух американцев, ибо все, что делают испанцы в области IT — УГ. Однако как уже было упомянуто, основная ценность любой соцсети — количество людей. Tuenti среди испанцев не пользуется даже десятой долей популярности, нежели FB. Да и сама идея не просматривается четко — национальная соцсеть? элитная соцсеть? соцсеть определенной возрастной категории??? Куда она будет расти — тоже не понятно. С телефониковским баблом — в Латинскую Америку. И дальше что? Продаваться ФБ? Словом, очередной пузырь?