Ну веб приложения (из заголовка опроса) и обобщение «веб» (некоторые могут подумать что просто сайты) это все же наверное разные вещи, в моем понимании приложения должны предоставлять некоторые сервисы, выполянть бизнес логику, иметь задел на расширение функционала, код должен быть способным подвергаться авто-рефракторингу, и тд. Например использовать JS со всем его прелестями еще и на серверной стороне я бы не стал.
Другое дело писать на JS серверный код. По мне так как минимум не очень дальновидно, да наверно это модно, для души например блог смастерить или todo'шку, но жертвы тоже нужно учитывать (писать большой проект разношерстной командой используя динамический язык программирования как основу серверного кода наверное весело).
Просто абзац «Быстрая компиляция проекта» выглядит так как будто раньше в IDEA не было автоматической компиляции в фоне, по мере изменений и тд. Но отдельный процесс это нарвено хорошо, стабильность, масштабирование, отсутствие лагов UI.
Но да, на самом деле я не много знал и знаю об IDEA, разве что некоторые знакомые называют лучшей IDE для разработки на Java. Пока что обхожусь Eclipse, привычка, но может быть когда нибудь меня склонят на темную сторону IDEA :)
>>> Стало возможным компилировать проект автоматически, в фоновом режиме, после каждого изменения в исходном коде, а значит, запускать приложение вы можете практически мгновенно.
То есть инкрементная компиляция как в Eclipse (с незапамятных времен)?
По приведенному примеру помогли комментарии к методу, в стиле API дока.
>>> Языки с неявной типизацией тяготеют к write-only-коду.
Ага, некоторые просто напишут что нужно в виде отдельной функции, причем часто в глобальном пространстве и довольны, а ведь тут как нигде важна жесткая стандартизированная структура кода (конвенции, модульность, паттерны и тд), чтобы хоть как-то облегчить дальнейшую поддержку и развитие подобного «динамического» кода. Хотя бы модульность и классовый подход использовать желательно.
Автоматический рефрактор (в том числе иерархия всех классов в одни-два клика, иерархия вызовов метода и тд) не является преимуществом статической типизации? Только не нужно утверждать что статический анализ кода позволит сделать тоже самое для динамического языка программирования (в JS можно всяких замыканий наворотить что анализатору будет не легко это разбирать).
>>> Легкость в освоении — языки с динамической типизацией обычно очень хороши для того, чтобы начать программировать.
А еще гики любят :)
>>> Я мог бы вам порекомендовать рассмотреть проблему с разных сторон, она не такая плоская что-бы так категорично утверждать что способ который комфортен вам идеально подходит каждому.
Согласен, это часто зависит от самого проекта. Например на небольших/непродолжительных проектах (которые например никогда не станут например базовым решением, основой для других проектов) можно наоборот обкатывать новые модные плюшки без особых плачевных последствий. Но в основном я работал с Java EE монстрами, наверно это оставило свой след :)
Смысл использования к примеру YUI3 в том что оно позволяет свести использование сторонних плагинов к минимуму. По поводу адаптера и замены реализации библиотек, имелось ввиду что это было бы полезно при исопользовании сторонних плагинов, не входящих в состав основного фреймворка, которые имеют аналоги, но этим никто не занимается, в JS основном везде хардкод, что часто объяснимо (далеко не во всех проектах целесообразно поддерживать структура проекта гибкой). А используя YUI об этом вообще не нужно думать, так как библиотека довольно самодостаточна, это не тоже самое что использовать jquery+backbone+underscore+jqueryui+bootstrap + еще чего-то «модного» найденного в сети.
>>> Ничего личного, но ваше мнение и устоявшаяся терминология не имеет ничего общего.
Разумеется, об этом и речь, немного расширил понятие связности только для того чтобы было понятнее что тут она тоже присутствует и это тоже не особо хорошо (я как-то рефакторил большой проект, где разработчики разных поколений пихали туда все что им было по душе, разгребать такое потом не весело).
Если все еще не понятно, то я расширил понятие связности, добавив сюда сильную и жесткую завязанность на сторонние библиотеки. Отсутствие жесткой завязанности на сторонние библиотеки в моем понимании это возможность быстро заменить одну реализацию другой реализацией (одну библиотеку на другую).
«site.users.comments» это наверно скорее структура модели, если я верно предположил о чем идет речь. Связность по моему больше применима к взаимодействию модулей системы (сирвайс слой, бизнес логика), а не модели.
Жесткая (предполагаю что мало кто делает фасад между сторонним плагином и своим проектом, чтобы при необходимости можно было более просто отвязаться от конкретного плагина и заменить другим) завязанность на множество сторонних плагинов живущих своей жизнью, да это связность в моем понимании.
Это jquery way, расширение возможностей за счет сторонних плагинов, разбросанных по интернету, живущих своей жизнью. Если немного перефразировать, то это называется усиления связности (coupling), а в программировании принято наоборот уменьшать связность (decoupling), но пользователей jquery понять можно, потому что часто это именно пользователи, а не разработчики :) Из-за специфики разработки (обычно крупные проекты, где работает много разработчиков, то есть пихать сюда какие попало плагины не вариант), мне обычно больше симпатизирует вариант когда фреймворк самодостаточен, то есть там есть средства работы с DOM, набор готовых виджетов, возможность использования MVC стиля разработки и тд. В этом случае можно быть уверенным, что все модули фреймворка совместимы между собой в любой момент времени, что поддержкой и развитием занимается одна команда, что не нужно лазить по сети в поисках очередного плагина или его обновления. Такие фреймворки существуют, как минимум это YUI3 и ExtJS (ко второму отношусь без симпатии).
>> 5Вт = честный эквивалент 60Ватт
Не все современные лампы выдадут такой показатель, а 2 годовой давности подавно. Поверю 7-8Ватт ~ 60Ватт накаливания, без учета спектра конечно.
У меня Turtle Beach Ear Force Z11, нормальная недорогие наушники с микрофоном, к тому же по дизайну не такие пафосные/гламурные/дворовые как представленные в обзоре (я бы такое бесплатно на голову не одел).
Если только wifi, то возможно лучшим вариантом будет что-то вроде Chuwi V99 (или аналог, они уже начали появляться), новое поколение китайских планшетов.
Но да, на самом деле я не много знал и знаю об IDEA, разве что некоторые знакомые называют лучшей IDE для разработки на Java. Пока что обхожусь Eclipse, привычка, но может быть когда нибудь меня склонят на темную сторону IDEA :)
То есть инкрементная компиляция как в Eclipse (с незапамятных времен)?
>>> Языки с неявной типизацией тяготеют к write-only-коду.
Ага, некоторые просто напишут что нужно в виде отдельной функции, причем часто в глобальном пространстве и довольны, а ведь тут как нигде важна жесткая стандартизированная структура кода (конвенции, модульность, паттерны и тд), чтобы хоть как-то облегчить дальнейшую поддержку и развитие подобного «динамического» кода. Хотя бы модульность и классовый подход использовать желательно.
>>> Легкость в освоении — языки с динамической типизацией обычно очень хороши для того, чтобы начать программировать.
А еще гики любят :)
PS сам пишу на Java и JavaScript.
Согласен, это часто зависит от самого проекта. Например на небольших/непродолжительных проектах (которые например никогда не станут например базовым решением, основой для других проектов) можно наоборот обкатывать новые модные плюшки без особых плачевных последствий. Но в основном я работал с Java EE монстрами, наверно это оставило свой след :)
>>> Ничего личного, но ваше мнение и устоявшаяся терминология не имеет ничего общего.
Разумеется, об этом и речь, немного расширил понятие связности только для того чтобы было понятнее что тут она тоже присутствует и это тоже не особо хорошо (я как-то рефакторил большой проект, где разработчики разных поколений пихали туда все что им было по душе, разгребать такое потом не весело).
«site.users.comments» это наверно скорее структура модели, если я верно предположил о чем идет речь. Связность по моему больше применима к взаимодействию модулей системы (сирвайс слой, бизнес логика), а не модели.
Не все современные лампы выдадут такой показатель, а 2 годовой давности подавно. Поверю 7-8Ватт ~ 60Ватт накаливания, без учета спектра конечно.