А вы не проводите анализ по используемым библиотекам в приложениях ваших клиентов? Была бы весьма интересная статистика.
Выковыривать данные тоже просто. Если это .ear или .war файлы, то внутренняя структура у них жестко определена стандартом. С учетом того, что многие для сборки проектов используют dependency management tools вроде Maven или Ivi, названия файлов библиотек будут содержать в себе номера версий.
Тут проблема в том, что о мультикарте знают очень немногие, и в основном из бывшего СССР. Соответственно, и карты просматривают в основном местные: России, Украины и других бывших республик. Я, например, гораздо чаще ищу что-то в своем городе, чем, скажем, просматриваю без дела просторы Никарагуа.
Карты Bing на наших просторах очень и очень слабые. Неудивительно, что постепенно они проигрывают OSM, ведь у последних постоянно растет детализация. С другой стороны, и Яндекс, и Гугл карты обновляют. Яндекс делает это чаще — субъективно — и получается у них лучше, особенно по части дополнительных сервисов: и пробки, и расписания, и адреса Яндекса постоянно радуют, чего не скажешь о Google. Но тут борьба идет ноздря в ноздрю, так что наверняка доли будут плавать между этими двумя сервисами.
Про OpenStreetMap слышали немногие и для большинства название сервиса теряется в списке других малоизвестных вроде ProGorod, Kosmosnimki и Visicom.
Ну, конечно, все эти истории нелицеприятны. Но одно дело, когда одна компания атакует другую, или когда один проект нападает на другой. Но нападение на стандарт — это совсем не в какие ворота.
У Столмана в свое время был весьма активный публичный спор с Хоконом Виум Ли — создателем CSS. Первый утверждал, что самое важное — наличие открытых исходных кодов. Второй — наличие и поддержка стандартов. Стандарты позволяют иметь несколько совместимых и взаимозаменяемых реализаций, причем не важно, открыты ли их исходники или нет. В стремлении к стандартизации гораздо больше свободы, чем в свободном ПО.
Как бы на то оно и sdandard body, чтобы воровать и раздавать всем. Ничего плохого в этом нет. Другое дело, что сами W3C считают, что лучше вначале прийти к ним, написать Working Draft, пообсуждать, довести дело до Candidate Recomendation, и уже потом что-то делать. Но если б все так делали, мы бы только-только дожили бы до стандартизации XmlHttpRequest.
В SL2 архитектура плагинов, совместимая с TextMate. Попробуйте нагуглить хороший плагин на TM и поставить себе (я не уверен, есть ли такой для Perl, но я так решил проблему с CoffeeScript).
Все по делу, хотя сегодня в мире Java и .NET многие тоже от SOAP отказываются. Сгенерировать REST-клиента на WCF тоже можно, а на стороне Java (которая REST-сервисом оказывается чаще, чем клиентом), есть JAX-RS API, которое в целом проще для понимания и для реализации, чем JAX-WS (последний считает, что вебсервис должен представлять собой EJB).
Много лет назад, в далеком 2007, когда вручную собирал WSDL, и по нему делал сервис и клиент на JAX-RPC, мечтал о том дне, когда банк перейдет наконец-таки с Java 1.3 хотя бы на Java 1.5, и можно будет описывать все аннотациями JAX-WS.
И вот прошло время, и сегодня я с ужасом думаю, что может понадобиться работать с SOAP.
И продолжая тему JS-движков, хочу спросить, почему не попробовали Rhino? Это порт SpiderMonkey на JVM, который с определенной версии включили в официальную поставку Java. Rhino имплементит стандарт EcmaScript 3, а также некоторые расширения от Mozilla, в первую очередь E4X — XML литералы в JS. Из-за этого Rhino иногда отдают предпочтение, если работать с XML придется много. Вторым немаловажным преимуществом перед Node JS является сборщик мусора из Java, который отличается гораздо большей предсказуемостью. Особенно это важно для процессов на сервере, когда latency оказывается важнее простой скорости.
Rhino используется в Yahoo, где на нем работают сервисы YQL и YAP. Выбрали его как раз из-за предсказуемого GC и поддержки XML.
При бенчмаркинге Rhino нужно учитывать особенности Java — медленный стартап и «прогрев». Рекомендуется запустить бенчмарк минут на 10, и только после этого собирать показания. Ну и да, тюнинг JVM — дело тонкое, и не факт, что нет какой-то комбинации настроек, которая смогла бы повысить производительность системы.
По идее Rhino должен уступать Node JS из-за оверхеда, связанного с трансляций инструкций SpiderMonkey в Java bytecode.
Блин, я говорю, что они достаточно быстрые, а все думают, что я их упрекаю в том, что они медленные.
Андроид использует managed-среду: приложения выполняются на виртуальной машине. При этом проблем с батареей или ресурсами не возникает. Значит, и .net-приложения могут нормально работать в условиях экономии ресурсов. Поэтому я не считаю точку зрения автора, что-де .NET не подходит для мобильных устройств и нужно заменять их нативными, ошибочной.
А я вам тогда встречный вопрос: какого черта для .NET и C++/CX используется XAML, а для Metro-приложений на JavaScript — HTML?
JavaScript — Такой же нормальный язык программирования. В стандарте ECMAScript нигде не написано, что выполняться он должен в браузере, что есть такие объекты, как window, document, etc. Почему же Микрософт решила не использовать кастомное Metro-API для построения интерфейса пользователя, но при этом оставила кастомное Metro-API для графики?
На лицо прагматизм: Микрософт решает использовать свой browser engine — Trident — для Метро-приложений. Но поскольку они не вносят реализацию WebGL в свой движок по политическим причинам, они оказываются перед выбором: либо не давать доступ к ускоренной графике для JS-Metro-приложений, и тем самым делая их приложениями второго сорта, либо прикручивать какое-то свое API.
При этом, если бы они ввели поддержку WebGL в IE, то разработчик мог бы портировать свое HTML5 веб-приложение на Windows 8 без особых трудозатрат. Этого не происходит, к нашему глубочайшему сожалению.
Я понимаю, что Win8-приложения — это не просто HTML5-приложения. У них есть доступ к файловой системе, к каким-то возможностям аппаратной платформы (тот же акселерометр и т.п.). На настоящее время далеко не для всех аспектов железа есть соответствующие стандарты W3C, хотя подвижкиестьужедавно. И я не стал бы упрекать Микрософт за создание собственных API в этих областях.
НО! Графика — это другой случай. Есть стандарт — WebGL, который поддерживают все движки, кроме IE. Микрософт не заявляет о нежелании его поддерживать, но и молчит о прогрессе в данном направлении. В компании продолжают гнуть свою линию в пользу того, что high-performance графика в вэбе — это удел плагинов (в первую очередь, Silverlight, ага). И ничего с этим поделать, видимо, не удастся.
И да, это проблема. И кричать «какого х*я» тут нечего.
Симпатичный пример. Вопрос в зал: какие есть способы оптимизации интерактивного рисования на канвасе? Есть ли, например, смысл делать два канваса один под другим и использовать double buffering. Есть ли способы использовать canvas совместно с WebWorkers? У нас несколько агентов рисуют на одном инструменте, и хотелось бы, чтобы в момент, когда один скрипт загружает в канвас изображения, другие агенты не задерживались.
При этом я сам всецело за Windows 8 — мне она очень и очень нравится, и приложения для нее я писать собираюсь. Но то-то я, а вот что по этому поводу думает бизнес — это уже совсем другой вопрос.
1. .NET достаточно быстр для широкого класса приложений. Если вам кажется, что он слишком медленный / жрет батарею и память, посмотрите на Андроид.
2. Поддержка C++ — это громко сказано. Она декларируется, но на деле мы имеем худшую среди всех компиляторов поддержку стандарта C++11 и кастомные расширения языка, применимые только для WinRT. На деле «ренессанс C++» — это объединение C++ и C++/CLI в новое поделие C++/CX.
3. HTML5 — опять маркетинг. Кастомное графическое API в Метро-приложениях вместо нормальной кроссбраузероной поддержки WebGL.
Ваши ремарки насчет IE10 справедливы и для IE9 — по ощущениям он работает быстрее, чем Chrome, уже и в Win7. Просто в IE вся графика построена на GPU, в то время как в остальных браузерах пока что оптимизировали только отдельные элементы (font renderring и canvas).
О том, что надо кидаться писать новые Метро-приложения, я бы говорил с осторожностью. Зачем делать Метро-апп, если можно сделать вэб-приложение, которое будет доступно пользователям всех операционных систем? Особенно, в условиях, когда вы выбираете фримиум-модель или чистую рекламу для монетизации, первоначальная стоимость размещения приложений, а также стоимость средств разработки, может быть очень велика.
Кроме того, не совсем ясно, насколько быстро будет происходить переход на новую версию ОС. Win7 рискует оказаться новой WinXP для бизнеса: ее возможностей сегодня более чем хватает для любой компании. А корпоративные пользователи — это большая доля рынка для Windows. Смысл тогда писать метро-приложение, если им смогут воспользоваться лишь немногие? Не лучше ли написать приложение под Win7, которое будет работать везде? А затем писать приложение для iPad, Android, Mac — это гораздо более весомые сегменты рынка.
Дельно. Вопрос в зал: а что — swift всегда с комиссией? И зависит ли комиссия от банка? Просто в ближайшее время нужно будет воспользоваться, и при этом личного счета в банке нет — придется открывать.
Выковыривать данные тоже просто. Если это .ear или .war файлы, то внутренняя структура у них жестко определена стандартом. С учетом того, что многие для сборки проектов используют dependency management tools вроде Maven или Ivi, названия файлов библиотек будут содержать в себе номера версий.
Карты Bing на наших просторах очень и очень слабые. Неудивительно, что постепенно они проигрывают OSM, ведь у последних постоянно растет детализация. С другой стороны, и Яндекс, и Гугл карты обновляют. Яндекс делает это чаще — субъективно — и получается у них лучше, особенно по части дополнительных сервисов: и пробки, и расписания, и адреса Яндекса постоянно радуют, чего не скажешь о Google. Но тут борьба идет ноздря в ноздрю, так что наверняка доли будут плавать между этими двумя сервисами.
Про OpenStreetMap слышали немногие и для большинства название сервиса теряется в списке других малоизвестных вроде ProGorod, Kosmosnimki и Visicom.
У Столмана в свое время был весьма активный публичный спор с Хоконом Виум Ли — создателем CSS. Первый утверждал, что самое важное — наличие открытых исходных кодов. Второй — наличие и поддержка стандартов. Стандарты позволяют иметь несколько совместимых и взаимозаменяемых реализаций, причем не важно, открыты ли их исходники или нет. В стремлении к стандартизации гораздо больше свободы, чем в свободном ПО.
Много лет назад, в далеком 2007, когда вручную собирал WSDL, и по нему делал сервис и клиент на JAX-RPC, мечтал о том дне, когда банк перейдет наконец-таки с Java 1.3 хотя бы на Java 1.5, и можно будет описывать все аннотациями JAX-WS.
И вот прошло время, и сегодня я с ужасом думаю, что может понадобиться работать с SOAP.
Никто не отменяет и более традиционных альтернатив: Postgre, MySQL или Firebird.
Не забудем также и про Derby DB.
Хотя для Node JS более естественным выбором может оказаться Mongo, Couch или Riak.
Rhino используется в Yahoo, где на нем работают сервисы YQL и YAP. Выбрали его как раз из-за предсказуемого GC и поддержки XML.
При бенчмаркинге Rhino нужно учитывать особенности Java — медленный стартап и «прогрев». Рекомендуется запустить бенчмарк минут на 10, и только после этого собирать показания. Ну и да, тюнинг JVM — дело тонкое, и не факт, что нет какой-то комбинации настроек, которая смогла бы повысить производительность системы.
По идее Rhino должен уступать Node JS из-за оверхеда, связанного с трансляций инструкций SpiderMonkey в Java bytecode.
Как человек, работающий с вебом, может легко использовать свои веб-скилы, если стандартное API заменено на MS-specific?
Андроид использует managed-среду: приложения выполняются на виртуальной машине. При этом проблем с батареей или ресурсами не возникает. Значит, и .net-приложения могут нормально работать в условиях экономии ресурсов. Поэтому я не считаю точку зрения автора, что-де .NET не подходит для мобильных устройств и нужно заменять их нативными, ошибочной.
Я защищаю .NET, а не нападаю на него.
JavaScript — Такой же нормальный язык программирования. В стандарте ECMAScript нигде не написано, что выполняться он должен в браузере, что есть такие объекты, как window, document, etc. Почему же Микрософт решила не использовать кастомное Metro-API для построения интерфейса пользователя, но при этом оставила кастомное Metro-API для графики?
На лицо прагматизм: Микрософт решает использовать свой browser engine — Trident — для Метро-приложений. Но поскольку они не вносят реализацию WebGL в свой движок по политическим причинам, они оказываются перед выбором: либо не давать доступ к ускоренной графике для JS-Metro-приложений, и тем самым делая их приложениями второго сорта, либо прикручивать какое-то свое API.
При этом, если бы они ввели поддержку WebGL в IE, то разработчик мог бы портировать свое HTML5 веб-приложение на Windows 8 без особых трудозатрат. Этого не происходит, к нашему глубочайшему сожалению.
Я понимаю, что Win8-приложения — это не просто HTML5-приложения. У них есть доступ к файловой системе, к каким-то возможностям аппаратной платформы (тот же акселерометр и т.п.). На настоящее время далеко не для всех аспектов железа есть соответствующие стандарты W3C, хотя подвижки есть уже давно. И я не стал бы упрекать Микрософт за создание собственных API в этих областях.
НО! Графика — это другой случай. Есть стандарт — WebGL, который поддерживают все движки, кроме IE. Микрософт не заявляет о нежелании его поддерживать, но и молчит о прогрессе в данном направлении. В компании продолжают гнуть свою линию в пользу того, что high-performance графика в вэбе — это удел плагинов (в первую очередь, Silverlight, ага). И ничего с этим поделать, видимо, не удастся.
И да, это проблема. И кричать «какого х*я» тут нечего.
1. .NET достаточно быстр для широкого класса приложений. Если вам кажется, что он слишком медленный / жрет батарею и память, посмотрите на Андроид.
2. Поддержка C++ — это громко сказано. Она декларируется, но на деле мы имеем худшую среди всех компиляторов поддержку стандарта C++11 и кастомные расширения языка, применимые только для WinRT. На деле «ренессанс C++» — это объединение C++ и C++/CLI в новое поделие C++/CX.
3. HTML5 — опять маркетинг. Кастомное графическое API в Метро-приложениях вместо нормальной кроссбраузероной поддержки WebGL.
Ваши ремарки насчет IE10 справедливы и для IE9 — по ощущениям он работает быстрее, чем Chrome, уже и в Win7. Просто в IE вся графика построена на GPU, в то время как в остальных браузерах пока что оптимизировали только отдельные элементы (font renderring и canvas).
О том, что надо кидаться писать новые Метро-приложения, я бы говорил с осторожностью. Зачем делать Метро-апп, если можно сделать вэб-приложение, которое будет доступно пользователям всех операционных систем? Особенно, в условиях, когда вы выбираете фримиум-модель или чистую рекламу для монетизации, первоначальная стоимость размещения приложений, а также стоимость средств разработки, может быть очень велика.
Кроме того, не совсем ясно, насколько быстро будет происходить переход на новую версию ОС. Win7 рискует оказаться новой WinXP для бизнеса: ее возможностей сегодня более чем хватает для любой компании. А корпоративные пользователи — это большая доля рынка для Windows. Смысл тогда писать метро-приложение, если им смогут воспользоваться лишь немногие? Не лучше ли написать приложение под Win7, которое будет работать везде? А затем писать приложение для iPad, Android, Mac — это гораздо более весомые сегменты рынка.