Я, к своему сожалению, не представляю, как вирусы или малвар могут попасть в мой комп со страницы, не содержащей плагинов — а плагины я включаю только ондеманд — т.е. фактически включаю его только для просмотра музыки и видео. Подозреваю, что на моем компе бывают только swfы от примерно десятка сайтов, и все это — плееры. Фишинг и CSRF — совсем другое дело, и антивирус тут не поможет.
В контакте зараза может быть, однако вероятность ее наличия там намного меньше, чем на других сайтах. Назову причины:
1. Наличие контента со сторонних вебсервисов сведено к минимому. Все баннеры показываются с серверов контакта и проходят модерацию. Вся музыка хостится напрямую, а не инжектится iframe мами с других источников. То же самое касается практически всех видео. Это означает, что все, происходящее на странице, контролируется самой командой контакта.
2. Контакт — большой сервис, и заражение на больших сайтах намного менее вероятно, чем на сайтах с небольшой посещяемостью. Если что-то и появится, вероятность того, что проблему обнаружат до того, как ты встретишься с ней лично, существенно выше.
Но я не хочу спорить беспредметно. Расскажите мне, как антивирус может помочь в плане безопасности человеку при условии, что:
— он не пользуетя USB-устройствами;
— у него включены все обновления;
— он качает софт только с официальных сайтов;
— у него не установлены никакие плагины, кроме флэша;
— он включает флэш только по требованию;
— периодически этот человек запускает на своем компе онлайн-сканер, за 7 лет ни один онлайн-сканер ни разу не нашел у меня ничего подозрительного.
Да, однажды страшные злодеи сломают YouTube и подложат что-то очень страшное и нехорошее в код плеера. Но какова вероятность такого события? И стоит ли опасность того, чтобы твой комп постоянно тормозил от антивируса? Моему на днях как раз семь лет исполнится, в плане железа он слабее, чем обычный телефон.
В контакте можно найти фильмы и на английском, и на украинском, и на испанском, и на многих других языках — с субтитрами или без, и в хорошем качестве. У меня монитор 1280 на 800, 720p на таком хватает с лихвой.
Антивирус на машине никогда не стоял, вирусы ловил от родственников в те далекие времена, когда пользовался флэшками. Если флешки не использовать, не ходить по странным сайтам, не качать чего попало, то вирусня обойдет вас стороной. Лучшие защитники от вирусов:
1. Плагины-on-demand — включаем флэш только когда надо.
2. В качестве pdf-ридера используем Хром.
3. В качестве ридера для .doc и прочих офисных файлов — Google Docs.
4. Передаем файлы через email — все мейл-провайдеры проверяют вложения антивирусом.
5. Не ходим куда попало. Фильмы, музыка и даже порно есть в контакте.
6. Сторонний софт — качаем только с официальных сайтов. Если платный — ищем бесплатные аналоги. Если уж решили стырить, то качаем с популярного треккера и только проверенные раздачи. Если страшно, ставим софт в виртуалку.
Во-первых, написано, что «так работает быстрее, чем эдак», а ссылок на тесты jsperf.com, подтверждающих все сказанное, нет. Все ваши домыслы относительно производительности могут иметь лишь отдаленное отношение к тому, что на самом деле происходит внутри JS VM. Исходить надо из того, что в браузерах «горячий код», который в основном и влияет на производительность, проходит через оптимизационный JIT, который и так весьма и весьма хорош.
Во-вторых, спорным является усложнение кода и уход от общепринятых идиом в угоду некому минимальному приросту производительности. Самое важное для любого кода — легкость поддержки.
В-третьих, все разговоры о производительности нужно начинать со слов «запускаем профайлер.» Профайлер есть доже в F12 tools IE8, и очень жаль, что знают о его существовании и умеют им пользоваться только единицы.
Единственный полезный совет на всю статью — использование DocumentFragments — но, если вы используете для DOM-манипуляций jQuery, то там об этом уже позаботились за вас.
Мы вот сейчас как раз и работаем со слайдами. В 20 гигабайт они уже давно не укладываются. Пока что за основу берется 30 гигов на техническое изображение «стандартного» размера. Каждый слайд проходит несколько обработок, и после каждой обработки делается несколько снимков разными длинами волн. На выходе легко получаем от полтора до трех террабайт данных с одного медицинского слайда.
А если учесть, что по этим данным нужно прогонять какие-то алгоритмы обработки — выделить клетки на изображении, подсчитать их площадь, провести кластеризацию по размеру, кучности, цвету, количеству т.н. маркеров и т.п. Из всего этого потом тоже выходят огромные массивы данных: цифровые показатели, векторные карты или производные изображения.
И все это нужно подготовить к тому, чтобы иметь возможность просматривать изображения на обычной воркстанции — в нашем случае это браузер. При этом времени на все-про все дать нам объективно могут минут пять-десять, не больше. Ну, и само-собой, возможность редактирования изображения, интеграция с кучей информационных систем, медицинским оборудованием, а также отчетность, поддержка удаленных клиентов, планшетов с тач-интерфейсом.
В общем, работы много, но все это очень интересно. И самое главное — дело это очень нужное. Подобные системы нужны не в будущем и даже не сегодня, они были нужны еще вчера, лет пять назад. Другое дело, что производители медицинского софта явно опаздывают. И поэтому я считаю, что это — огромное поле для стартапов и для небольших команд (у нас в команде всего четыре разработчика).
Ну, Working Draft — это даже не Candidate Recommendation. Формально именно на стадии CR браузерам рекомендуется делать реализацию, причем желательно с вендор-префиксом. Префикс убирается на стадии Proposed Recommendation. Что-то браузеры тут вперед паровоза спешат.
Я считаю, есть смысл писать новость о релизе только в том случае, если продукт претерпел значительные изменения.
Например, новость о том, что в Микрософт решили поддержать SVG или EcmaScript5 в IE9 — значительна, т.к. огромное количество веб-разработчиков хотело бы использовать данные технологии.
С другой стороны, очередной секьюрити апдейт того же IE, закрывающий какую-то дырку из области эзотерических изысканий, — не тема для обсуждения.
Есть HTC HD2, вышедший на закате эпохи WinMobile. Его пользователи так расстроились, что девайс не подлежит апгрейду на WP7, что сами на него портировали и Андроид, и WP7, и iOS, и даже Windows 95.
тут вопрос не в том, что Микрософт — монополист. Как раз наоборот, на мобильных устройствах доля Микрософт — минимальна. Сегодня Windows Phone, а завтра и Windows 8 Metro оказываются связанными по рукам и ногам.
Нет пользователей — нет интереса разработчиков.
Нет интереса разработчиков — нет приложений.
Нет приложений — нет пользователей.
В Редмонде борятся за каждого пользователя. Только так им удастся остаться на рынке мобильных платформ. Они смотрят на других участников рынка, занимающих сходные позиции. Это в первую очередь WebOS и Blackberry Playbook. И те, и другие предоставили альтернативный стек технологий: HTML5 и Adobe AIR соответственно. И обе платформы проигрывают планшетный рынок именно из-за Android. RIM вообще разрешили запускать на своем планшете Android-приложения, а на планшет HP его портировали через несколько дней после выпуска. В результате для разработчиков пропал стимул писать специальные приложения для этих систем: их ответ — используйте Android.
Microsoft идет на блокировку загрузчика именно для того, чтобы ее планшеты не стали новым Плейбуком. Возможно, они будут продавать свои устройства по сниженной цене для того, чтобы набрать пользовательскую базу. И им не нужно, чтобы их устройства воспринималсь как «недопланшеты» — Playbook, Nook Color, Kindle Fire или HP Touchpad.
Линукс в классическом понимании (ядро, иксы, менеджеры пакетов) тут вообще никто не вспоминает. Вы же не ждете, что на iPad встанет Ubuntu. Чем тогда планшет с Win 8 такой особенный? Я сам, конечно, не против, но и позицию Microsoft и производителей устройств отлично понимаю.
Когда ребенку предлагают собрать робота и научить его каким-то трюкам (например, реагировать на команды, передаваемые цветным фонариком), ему любой язык программирования покажется незначительной преградой.
Возможно, толчком для этого как раз и послужил массовый исход лучших дизайнеров из Гугла несколько лет назад. В Google проекты долго обкатываются через горнило A/B тестинга. В результате многие смелые изменения отметаются на стадии тестирования, а изменения становятся мелкими и незаметными. Дизайн проигрывает в угоду эффективности. Достаточно вспомнить, как одно время менялся размер и положение логотипа Google на странице поиска. Можно было сидеть, обновлять страницу и видеть, как она немножко прыгает. Также долгое время размер логотипа зависел от браузера.
Сейчас вот перешли на другой стиль — стиль Google+. Но сколько он продержится в продуктах компании без существенных изменений? Может, пять лет, а может и десять. И поверьте мне, через десять лет всем будет казаться, что Гугл не меняется и что для хорошего дизайнера там нет ни работы, ни перспектив.
С другой стороны, во многих компаниях соответствующего калибра — Facebook, Microsoft, Apple — та же проблема: есть определенный стиль, которого надо придерживаться. Просто в случае с Google для дизайнеров устанавливаются гораздо более жесткие рамки.
Я завел ящик на Yahoo, когда увидел их рекламу на боку болидов команды Алена Проста Формулы 1. Тогда сильно болел и за Жана Алези, и за Оливье Паниса. О mail.ru, Яндексе или Google узнал гораздо позже.
Кстати, вопрос по этому поводу: позволят ли оптические технологии сделать сам процессор прозрачным? Сегодня уже есть технологии для создания прозрачных дисплеев и тач-панелей. Когда-то видел новость о прозрачной батарее. По большому счету до того, чтобы сделать прозрачный девайс, остались только микросхемы.
О том, почему прозрачность так важна, думаю, говорить не стоит.
9ка — ничего, даже ES5 поддерживает, а значит, потом будет возможность эмулировать ES6. Единственный по-настоящему большой недостаток — нет WebGL. Зато обычный 2d canvas — самый быстрый.
Я бы вам посоветовал начать с основного набора: vk, fb, lj. А затем по чуть-чуть добавлял остальное. Зачем, например, отказываться от одноклассников? Неудобное API — отложите, а потом, как будет время, — добавьте.
А я наоборот стараюсь поселяться поближе к работе. Сейчас 20 минут пешком, подкаст в ушах. Прихожу на работу пораньше: пока никого нет, тоже производительность высокая.
С ноутом не люблю на работу ездить. Просто для этого его надо с работы взять — а потом дома тянет его открыть, а там смотришь — уже работаешь. Когда один — это нормально, но я уж лучше время семье уделю.
Не надо убиваться! PHP имеет право на существование, хотя есть и другие скриптовые языки, которые также подходят для вэб-разработки. Уверен, вам вполне может понравиться Ruby, Python или JavaScript.
Так же и с Comic Sans — есть куча похожих на него шрифтов. Да и среди непохожих тоже есть неплохие. Вам нравится что-нибудь отсюда?
Хм, радует, что действительно время потратили — просто из первоначального поста я этого не увидел. Про большее потребление памяти JVM по сравнению с YAVR мне отлично известно: это проблема большинства языков на JVM. Все-таки виртуальная машина, созданная для того, чтобы эффективно исполнять байткод статического языка двадцатилетней давности, не очень-то подходит для динамического Ruby. JRuby внутри очень сложен. Полиморфные кэши методов и синтетические классы съедают дофига ресурсов. Плюс несколько компиляторов (насколько я помню, есть у них базовый интерпретатор и свой JIT). У того же Jython или Groovy та же проблема. И та же проблема у IronPython и IronRuby на CLR. Даже Rubinius на LLVM ест больше памяти.
Вообще перед любым разработчиком языка возникает эта дилемма: либо использовать существующую VM, либо писать свою с нуля. В первом случае получаешь готовые библиотеки для IO, Юникода, DateTime и т.п. Плюс не надо беспокоиться о JIT или GC. Но с другой стороны, все, что ты получаешь бесплатно, тебе не совсем подходит. Как вещи старшего брата: тут жмет, а тут наоборот слишком свободно.
Своя VM — дело трудоемкое, требует времени, но результат может оказаться лучше. Примеров масса:
— виртуальная машина для Java на базе LLVM+VMkit работает в разы медленнее, чем HotSpot;
— PyPy обгоняет и Jython, и IronPython;
— V8 и IonMonkey быстрее, чем Rhino;
Обратное тоже бывает: IronPython быстрее, чем CPython, например.
На мой взгляд, самое лучшее, что может быть с языком, — это несколько конкурирующих реализаций. Посмотрите на гонку v8, Caracan, SpiderMonkey — JavaScript за короткий срок переместился в топ самых быстрых языков программирования. И у Ruby ситуация похожа: YARV и JRuby в попытках обогнать друг друга ставят рекорды производительности, а MagLev и Rubinius подпирают их снизу. Каких-то пару лет назад Ruby безнадежно отставал от Питона, а сегодня они почти одинаковы.
Насчет вашего бенчмарка пара предложений:
1. Может, добавить логики в контроллер, а то простой Hello World мало что дает? Предлагаю что-то считать, поскреплять строки в цикле, поработать со списками. Было бы шикарно, если б еще и в базу данных заглядывал.
2. Попробуйте другой сервер. Я сомневаюсь, что те, кто ставит JRuby, пользуется «кирпичом». Либо Glassfish, либо Thin, либо еще что-то.
В контакте зараза может быть, однако вероятность ее наличия там намного меньше, чем на других сайтах. Назову причины:
1. Наличие контента со сторонних вебсервисов сведено к минимому. Все баннеры показываются с серверов контакта и проходят модерацию. Вся музыка хостится напрямую, а не инжектится iframe мами с других источников. То же самое касается практически всех видео. Это означает, что все, происходящее на странице, контролируется самой командой контакта.
2. Контакт — большой сервис, и заражение на больших сайтах намного менее вероятно, чем на сайтах с небольшой посещяемостью. Если что-то и появится, вероятность того, что проблему обнаружат до того, как ты встретишься с ней лично, существенно выше.
Но я не хочу спорить беспредметно. Расскажите мне, как антивирус может помочь в плане безопасности человеку при условии, что:
— он не пользуетя USB-устройствами;
— у него включены все обновления;
— он качает софт только с официальных сайтов;
— у него не установлены никакие плагины, кроме флэша;
— он включает флэш только по требованию;
— периодически этот человек запускает на своем компе онлайн-сканер, за 7 лет ни один онлайн-сканер ни разу не нашел у меня ничего подозрительного.
Да, однажды страшные злодеи сломают YouTube и подложат что-то очень страшное и нехорошее в код плеера. Но какова вероятность такого события? И стоит ли опасность того, чтобы твой комп постоянно тормозил от антивируса? Моему на днях как раз семь лет исполнится, в плане железа он слабее, чем обычный телефон.
1. Плагины-on-demand — включаем флэш только когда надо.
2. В качестве pdf-ридера используем Хром.
3. В качестве ридера для .doc и прочих офисных файлов — Google Docs.
4. Передаем файлы через email — все мейл-провайдеры проверяют вложения антивирусом.
5. Не ходим куда попало. Фильмы, музыка и даже порно есть в контакте.
6. Сторонний софт — качаем только с официальных сайтов. Если платный — ищем бесплатные аналоги. Если уж решили стырить, то качаем с популярного треккера и только проверенные раздачи. Если страшно, ставим софт в виртуалку.
Во-первых, написано, что «так работает быстрее, чем эдак», а ссылок на тесты jsperf.com, подтверждающих все сказанное, нет. Все ваши домыслы относительно производительности могут иметь лишь отдаленное отношение к тому, что на самом деле происходит внутри JS VM. Исходить надо из того, что в браузерах «горячий код», который в основном и влияет на производительность, проходит через оптимизационный JIT, который и так весьма и весьма хорош.
Во-вторых, спорным является усложнение кода и уход от общепринятых идиом в угоду некому минимальному приросту производительности. Самое важное для любого кода — легкость поддержки.
В-третьих, все разговоры о производительности нужно начинать со слов «запускаем профайлер.» Профайлер есть доже в F12 tools IE8, и очень жаль, что знают о его существовании и умеют им пользоваться только единицы.
Единственный полезный совет на всю статью — использование DocumentFragments — но, если вы используете для DOM-манипуляций jQuery, то там об этом уже позаботились за вас.
А если учесть, что по этим данным нужно прогонять какие-то алгоритмы обработки — выделить клетки на изображении, подсчитать их площадь, провести кластеризацию по размеру, кучности, цвету, количеству т.н. маркеров и т.п. Из всего этого потом тоже выходят огромные массивы данных: цифровые показатели, векторные карты или производные изображения.
И все это нужно подготовить к тому, чтобы иметь возможность просматривать изображения на обычной воркстанции — в нашем случае это браузер. При этом времени на все-про все дать нам объективно могут минут пять-десять, не больше. Ну, и само-собой, возможность редактирования изображения, интеграция с кучей информационных систем, медицинским оборудованием, а также отчетность, поддержка удаленных клиентов, планшетов с тач-интерфейсом.
В общем, работы много, но все это очень интересно. И самое главное — дело это очень нужное. Подобные системы нужны не в будущем и даже не сегодня, они были нужны еще вчера, лет пять назад. Другое дело, что производители медицинского софта явно опаздывают. И поэтому я считаю, что это — огромное поле для стартапов и для небольших команд (у нас в команде всего четыре разработчика).
Например, новость о том, что в Микрософт решили поддержать SVG или EcmaScript5 в IE9 — значительна, т.к. огромное количество веб-разработчиков хотело бы использовать данные технологии.
С другой стороны, очередной секьюрити апдейт того же IE, закрывающий какую-то дырку из области эзотерических изысканий, — не тема для обсуждения.
Нет пользователей — нет интереса разработчиков.
Нет интереса разработчиков — нет приложений.
Нет приложений — нет пользователей.
В Редмонде борятся за каждого пользователя. Только так им удастся остаться на рынке мобильных платформ. Они смотрят на других участников рынка, занимающих сходные позиции. Это в первую очередь WebOS и Blackberry Playbook. И те, и другие предоставили альтернативный стек технологий: HTML5 и Adobe AIR соответственно. И обе платформы проигрывают планшетный рынок именно из-за Android. RIM вообще разрешили запускать на своем планшете Android-приложения, а на планшет HP его портировали через несколько дней после выпуска. В результате для разработчиков пропал стимул писать специальные приложения для этих систем: их ответ — используйте Android.
Microsoft идет на блокировку загрузчика именно для того, чтобы ее планшеты не стали новым Плейбуком. Возможно, они будут продавать свои устройства по сниженной цене для того, чтобы набрать пользовательскую базу. И им не нужно, чтобы их устройства воспринималсь как «недопланшеты» — Playbook, Nook Color, Kindle Fire или HP Touchpad.
Линукс в классическом понимании (ядро, иксы, менеджеры пакетов) тут вообще никто не вспоминает. Вы же не ждете, что на iPad встанет Ubuntu. Чем тогда планшет с Win 8 такой особенный? Я сам, конечно, не против, но и позицию Microsoft и производителей устройств отлично понимаю.
Когда ребенку предлагают собрать робота и научить его каким-то трюкам (например, реагировать на команды, передаваемые цветным фонариком), ему любой язык программирования покажется незначительной преградой.
Втянутся — можно переходить на что-то другое.
Сейчас вот перешли на другой стиль — стиль Google+. Но сколько он продержится в продуктах компании без существенных изменений? Может, пять лет, а может и десять. И поверьте мне, через десять лет всем будет казаться, что Гугл не меняется и что для хорошего дизайнера там нет ни работы, ни перспектив.
С другой стороны, во многих компаниях соответствующего калибра — Facebook, Microsoft, Apple — та же проблема: есть определенный стиль, которого надо придерживаться. Просто в случае с Google для дизайнеров устанавливаются гораздо более жесткие рамки.
О том, почему прозрачность так важна, думаю, говорить не стоит.
Насчет остального (производительность, native bind и т.д.) — что-то уже есть в 11.60, а что-то будет в 12й.
Другое дело, что у вас требования по поддержке жестче: 10.6 и выше. Тогда вам не позавидуешь. Кстати, не пересмотрели требования по браузерам?
С ноутом не люблю на работу ездить. Просто для этого его надо с работы взять — а потом дома тянет его открыть, а там смотришь — уже работаешь. Когда один — это нормально, но я уж лучше время семье уделю.
Так же и с Comic Sans — есть куча похожих на него шрифтов. Да и среди непохожих тоже есть неплохие. Вам нравится что-нибудь отсюда?
Вообще перед любым разработчиком языка возникает эта дилемма: либо использовать существующую VM, либо писать свою с нуля. В первом случае получаешь готовые библиотеки для IO, Юникода, DateTime и т.п. Плюс не надо беспокоиться о JIT или GC. Но с другой стороны, все, что ты получаешь бесплатно, тебе не совсем подходит. Как вещи старшего брата: тут жмет, а тут наоборот слишком свободно.
Своя VM — дело трудоемкое, требует времени, но результат может оказаться лучше. Примеров масса:
— виртуальная машина для Java на базе LLVM+VMkit работает в разы медленнее, чем HotSpot;
— PyPy обгоняет и Jython, и IronPython;
— V8 и IonMonkey быстрее, чем Rhino;
Обратное тоже бывает: IronPython быстрее, чем CPython, например.
На мой взгляд, самое лучшее, что может быть с языком, — это несколько конкурирующих реализаций. Посмотрите на гонку v8, Caracan, SpiderMonkey — JavaScript за короткий срок переместился в топ самых быстрых языков программирования. И у Ruby ситуация похожа: YARV и JRuby в попытках обогнать друг друга ставят рекорды производительности, а MagLev и Rubinius подпирают их снизу. Каких-то пару лет назад Ruby безнадежно отставал от Питона, а сегодня они почти одинаковы.
Насчет вашего бенчмарка пара предложений:
1. Может, добавить логики в контроллер, а то простой Hello World мало что дает? Предлагаю что-то считать, поскреплять строки в цикле, поработать со списками. Было бы шикарно, если б еще и в базу данных заглядывал.
2. Попробуйте другой сервер. Я сомневаюсь, что те, кто ставит JRuby, пользуется «кирпичом». Либо Glassfish, либо Thin, либо еще что-то.
Вообще интересно, что получится.