Непонятно, у кого останутся права на алгоритмы _кодирования_, поскольку совершенно недостаточно открыть математику формата и предоставить даже самый навороченный _декодировщик_ для пользовательских приложений. У On2 на лицензировании кодеков построен совершенно отельный бизнес, не считая того, что Google пользуется ими теперь совершенно безвозмездно. Так что если обычным владельцам сайтов не будет предоставлен бесплатный инструмент для кодирования видео, то этот шаг можно считать лишь укреплением «линейки» продуктов Google — скажем, HD на Youtube будет доступен только в VP8 в тех браузерах, которые пожелают включить кодек в дистрибутив. Большинство же остальных сайтов будет продолжать использовать 264 или будет вынуждено сотрудничать с CDN, у которых есть VP8.
Дома вместо коврика использую лист бумаги А4, меняю по мере загрязнения, крепится к столу сантехническим скотчем, который не оставляет следов клея. Самый удобный вариант для меня.
Да там сдвинутых на теме религии идиотов гораздо больше. Публично назвать себя атеистом может позволить себе не каждый, и во многих сообществах это автоматически будет означать начало серьезных проблем с карьерой и прочей социализацией.
Этот продукт — сам по себе вреднее любого вируса, его замечательные механизмы «эвристики, сканирования и раннего обнаружения» не работают на 90% вирусов и, тем более, на загрузчиках, которые хорошо прячутся. Не раз видел, как пользователи, успокоенные зеленой иконкой, разводили себе целый зоопарк, от которого компьютер в итоге просто дох. Ужасное говно.
Dual Boot — с Windows Home Edition по умолчанию, и серверным линуксом на шифрованном разделе. Даже при всем желании дальше загрузчика не попадут. Лого загрузчика можно также убрать.
А что стало со скоростью операций после перехода на специальные битовые массивы?
Выше написали, что скорость работы типа должна страдать из-за лишних операций, но мне кажется, что это вообще не очевидно и требуется эксперимент.
Вы замеряли, как ведет себя GC во время работы и вообще, что творится с памятью? Проект нестандартный, если напишете статью с цифрами, будет очень интересно.
А фиг знает, для изучения сервисов попробуйте, например, освоить стыковку визуальной части Flex-а или Ext через бекенд, предоставляющий доступ к сервисам с форматом выдачи в JSON или XML. Для этого можно, например, использовать Apache CXF. С SOAP можете не связываться, все равно не сможете применить куда-либо осмысленно. Напишите по результатам статью, переведите ее на английский язык, вставьте там скриншотики и выложите где-нибудь — этого будет вполне достаточно, вопросы большинства работодателей по поводу вашей адекватности это покрывает с лихвой.
Обычно все понимают, что серьезный разработчик может и не знать в деталях какого-то конкретного фреймворка, но зато способен разобраться в том, как его использовать за конечное время и, главное, понимает, что на нем делать можно, а чего — нельзя, и во что это выльется. К сожалению, это приходит с опытом, однако, если много всего перепробовать и быть любознательным, то появляется здравый взгляд на многие вещи, который сильно помогает. Между тем, потратить время на то, чтобы разобраться, что из себя представляют JSF и Struts — просто необходимо — всегда нужно собственное мнение. Вдруг понравится.
Проект на джаве это, чаще всего, не один человек и даже иногда не одна команда. Я всегда обращаю внимание на то, упомянуты ли в резюме «инфраструктурные» инструменты — особенно Maven (или, хуже, Ant), умеет ли товарисч писать тесты, понимает ли, как произвести нагрузочное тестирование и как сделать из него правильные выводы, знаком ли с инструментами ведения проекта, например, багтрекером JIRA, знает ли SVN (попадаются и незнающие), может ли пользоваться линуксом (хотя бы перезапустить томкет и посмотреть, не кончилось ли место на диске). Очень хорошо посвятитеть некоторое время изучению java reflection (потому что это один из ключей к пониманию того, как jvm работает). На мой взгляд, тонкости владения языком совершенно не важны, если конечный продукт не умеет собираться с консоли или вы не можете обеспечить работу среды, в которой он будет выполняться. Использование правильных инструментов — это половина успеха, другая половина — это опыт. Нюансы, касающиеся именно программирования (некритичные для работоспособности, типа, как покрасивее написать) вообще не важны.
Не рекомендую, REST-бекенд, пара сервлетов c Velocity, обслуживающих шаблоны и Ext-JS или даже чистый jQuery дают лучший результат. GWT — чудовищно трудоемкий фреймворк
На мой взгляд, учиться нужно на множестве небольших примеров, осваивая каждую технологию в рамках того, что есть в ее официальной документации и пытаясь произвольно стыковать разные технологии так, как только придет вам в голову. Шанс самостоятельно подобрать правильную архитектуру для первого проекта на джаве стремится к 0, поэтому не имеет никакого смысла затевать что-то большое. Кроме того, не следует доверять курсам, мнениям старперов (моему, в частности) и вообще как-то заморачиваться. Дело в том, что в джава-мире обычно действуют большие группы, часто на технологиях, устаревших много лет назад, связанные долгосрочными отношениями с поставщиками решений. Поскольку каждый хочет казаться компетентным, существует множество людей, которых научили программировать в какой-то крупной компании, и они по инерции считают, что те или иные фреймворки — круты, несмотря на то, что архитектура была, возможно, выбрана исходя из того, поставщик какого сервера приложения откатил больше техническому решению или чему научился на курсах в предыдущей конторе ведущий разработчик. Следует избегать всего, что исходит от компаний-интеграторов — вовне их технологии неприменимы, а если уж вам доведется туда попасть, вас погрузят во все нюансы. Технологии «по документации» никогда не используются на больших проектах.
Eclipse принято советовать новичкам, поскольку он бесплатен. В нем все супер до тех пор, пока вы имеете дело с «чистым» джава-кодом, отладкой его и всем, что не выходит за рамки запуска единственного проекта с пом main(). Как только вы пытаетесь запустить произвольный сервер приложений, или хотите для фреймворка ХХХ пользоваться мастером (тем более, производить рефакторинг кода, написанного с использованием такого фреймворка), начинается геморрой, поскольку плагины либо написаны криворукими бесплатными разработчиками, либо плохо совместимы с текущей сборкой, либо не работают друг с другом и так далее и тому подобное. Мой опыт говорит, что чем потом терять в производительности, лучше сразу переучиться на IDEA. Достичь ее пределов довольно сложно, а глюки, если они и бывают, некритичны и исправляются быстро.
Не советую тратить много времени на изучение веб-фреймворков для джавы. Нужно идеально знать, как устроен сервлет-контейнер (пройтись по исходникам томкета и джетти), однако упаси вас бог по собственной воле встрять в разработку на JSF, Struts и прочем подобном. Продуктивность на таких проектах минимальна, никакие паттерны современной веб-разработки на эти фреймворки не ложатся, а получаемый результат зачастую уродлив. Для того, чтобы получить на подобных технологиях хотя бы удовлетворительный «сайт», придется вложить колоссальное количество усилий без гарантии, что код останется поддерживаемым. В то же время имеет смысл как можно больше внимания уделять технологиям интеграции — от организации веб-сервисов до серверов очередей.
1 сервер,
— «на котором крутился добрый десяток сайтов наших клиентов в т.ч. магазины с приличными оборотами»
— «хостился баг-трекер, джира, ДНС»
— это не правильно. Лучше 2, с разными административными входами. Извините, если что-то очевидное для вас написал.
Выше написали, что скорость работы типа должна страдать из-за лишних операций, но мне кажется, что это вообще не очевидно и требуется эксперимент.
Вы замеряли, как ведет себя GC во время работы и вообще, что творится с памятью? Проект нестандартный, если напишете статью с цифрами, будет очень интересно.
Обычно все понимают, что серьезный разработчик может и не знать в деталях какого-то конкретного фреймворка, но зато способен разобраться в том, как его использовать за конечное время и, главное, понимает, что на нем делать можно, а чего — нельзя, и во что это выльется. К сожалению, это приходит с опытом, однако, если много всего перепробовать и быть любознательным, то появляется здравый взгляд на многие вещи, который сильно помогает. Между тем, потратить время на то, чтобы разобраться, что из себя представляют JSF и Struts — просто необходимо — всегда нужно собственное мнение. Вдруг понравится.
Проект на джаве это, чаще всего, не один человек и даже иногда не одна команда. Я всегда обращаю внимание на то, упомянуты ли в резюме «инфраструктурные» инструменты — особенно Maven (или, хуже, Ant), умеет ли товарисч писать тесты, понимает ли, как произвести нагрузочное тестирование и как сделать из него правильные выводы, знаком ли с инструментами ведения проекта, например, багтрекером JIRA, знает ли SVN (попадаются и незнающие), может ли пользоваться линуксом (хотя бы перезапустить томкет и посмотреть, не кончилось ли место на диске). Очень хорошо посвятитеть некоторое время изучению java reflection (потому что это один из ключей к пониманию того, как jvm работает). На мой взгляд, тонкости владения языком совершенно не важны, если конечный продукт не умеет собираться с консоли или вы не можете обеспечить работу среды, в которой он будет выполняться. Использование правильных инструментов — это половина успеха, другая половина — это опыт. Нюансы, касающиеся именно программирования (некритичные для работоспособности, типа, как покрасивее написать) вообще не важны.
Eclipse принято советовать новичкам, поскольку он бесплатен. В нем все супер до тех пор, пока вы имеете дело с «чистым» джава-кодом, отладкой его и всем, что не выходит за рамки запуска единственного проекта с пом main(). Как только вы пытаетесь запустить произвольный сервер приложений, или хотите для фреймворка ХХХ пользоваться мастером (тем более, производить рефакторинг кода, написанного с использованием такого фреймворка), начинается геморрой, поскольку плагины либо написаны криворукими бесплатными разработчиками, либо плохо совместимы с текущей сборкой, либо не работают друг с другом и так далее и тому подобное. Мой опыт говорит, что чем потом терять в производительности, лучше сразу переучиться на IDEA. Достичь ее пределов довольно сложно, а глюки, если они и бывают, некритичны и исправляются быстро.
Не советую тратить много времени на изучение веб-фреймворков для джавы. Нужно идеально знать, как устроен сервлет-контейнер (пройтись по исходникам томкета и джетти), однако упаси вас бог по собственной воле встрять в разработку на JSF, Struts и прочем подобном. Продуктивность на таких проектах минимальна, никакие паттерны современной веб-разработки на эти фреймворки не ложатся, а получаемый результат зачастую уродлив. Для того, чтобы получить на подобных технологиях хотя бы удовлетворительный «сайт», придется вложить колоссальное количество усилий без гарантии, что код останется поддерживаемым. В то же время имеет смысл как можно больше внимания уделять технологиям интеграции — от организации веб-сервисов до серверов очередей.
Удач.