Solver

Выбранный вами вариант не плох, но пока не исправлена проблема с багом в контроллере я бы брать не стал. Хорошо показывают себя диски от Crucial, это дочерний бренд Micron (компании, которая как раз выпускает память для ssd), контроллер уже проверенный, прошивки отлажены, скорости честные (получите то, что заявлено на упаковке в реальных условиях, а не только в синтетике, чем грешат OCZ и другие на контроллерах Sandforce). В общем, советую.

>но тогда я не понимаю почему много разработчиков с макбуками? неужели они ставят виртуалку?

да, ставят, и сейчас расскажу как именно. чтобы все было по яблочному удобно.

самая главная проблема — это совместимость, понятно если ставится просто apache/php — то особых проблем нет,
но вот, если например проект серьезнее — nginx/zend server ce/mongodb+tomcat/memcache + imagemagik + модули на перле к nginx — с портами начинается ад

настроить все, чтобы работало также как на сервере — сложно, периодически появляются баги в устаревшей версии софта, порты обновляются явно реже.

я уж не говорю про баги самих портов (на 10.5 инсталл boost+python обновлял glibc и убивал макос).

вывод: порты держим только для малого количества программ (у меня порты вообще только для nmap и wget)

поэтому нам нужна виртуалка — плюсы очевидны:

— идентичность конфигурации с реальным сервером
— отсутствие проблем портирования\обновления софта

у меня из виртуалок живет VirtualBox. пробовал VMWare и Parallels — VB понравился больше, да и бесплатный он.

итак, при сетапе вируалки туда ставится таже ОС, что и на сервере — в моем случае это CentOS

на OS настраиваем все что нам нужно, а дальше — ставим NFS/Samba (можно конечно использовать и sshfs — но по скорости он явно проигрывает) — кстати Lion будет поддерживать NFSv4.

настраиваем key_authorization, чтобы не нужно было писать пароль при каждом логине, и прописываем алиес — sshvirt1 например, чтобы не приходилось постоянно писать айпи виртуалки.

далее — сохраняем образ, чтобы при сетапе новой вируалки нам не нужно было все повторять с начала.

запускаем вируалку, тестиш — все ок, монтируем сетевой диск — далее работаем с ним как со своим.

из среды — я пользуюсь Eclipse (и его производными)

для php у меня — zend studio, для python — aptana studio

можно конечно настроить аналог на чистом eclipse — но лень

еще из проблем связанных с портами — у меня мой пользовательский каталог зашифрован с помощью filevault (и бэкапится на iDisk через TimeMachine =)) — поэтому апач просто не имеет доступа. и как вариант — либо www_root держать за home, либо использовать виртуалку.

ну, как-то так =)

я бы написал подробную статью, как это все засетапить (с выходом лео, буду все это делать)
а там, сетап filevault2 с бэкапам на облако + настройка консоли и прочих плюшек, до я дико заминусован, так, что не знаю =)

Зависит от приложения и архитектурных требований.

Во-первых, компонентный или action-based?

Компонентные — легко писать (i.e. «разрабатывать большие сложные гуи») но долго разрабатывать кастомные компоненты, приложение будет в среднем тяжелее (медленнее) и будет жрать больше памяти (особенно JSF имплементации с conversation state сохраненным в HttpSession) на одного юзера. Кроме того, их нередко сложно кластеризовать из-за плохого использования сессии библиотеками.
Из компонентных: JSF (XxxFaces), Tapestry 5, GWT. Тапестри 5 не советую — имел опыт разработки большого публичного сайта на нем. Посоветовал бы попробовать GWT — слышал максимум положительных отзывов от людей, кто что-либо на нем делал. Опять-таки, лично я не советую JSF — сразу потеряете контроль за тем, что находится у вас в сессии, приложение станет «тяжелым».

Action-based фреймворки: чуть медленнее разработка, легко сделать приложение stateless и получить простую кластеризацию, приложение получается легковесным и быстрым.
Посоветую такие комбинации: Spring MVC + FreeMarker, Spring MVC + Velocity, Spring MVC + JSP 2 (EL-based). Слышал положительные вещи про Stripes (но он очевидно менее популярен, чем Spring MVC) и Play (всем хорош, кроме странных архитектурных закидонов — например, предлагается пихать бизнес-логику в модели, а не в выделенный сервис-леер. одно это скорее всего будет для вас критично).

Потом, что еще надо учесть —
1) HTML это не XML. Если движок шаблонов использует XML — это уже не очень хорошо. DOCTYPE, browser-specific комменты придется вставлять через хаки.
2) streaming, not buffering. Правильная работа с вебом — писать в outputStream по ходу, а не копить строчку и потом выбрасывать ее целиком. Почти все компонентные фреймворки грешат лишней буферизацией, многие action-based тоже. Отсюда завышенные требования к памяти, OOME при генерации тяжелых страниц, etc.
3) Обратите особое внимание на то, как в выбранном фреймворке сделаны Layouts — они должны быть удобные (ie. ближе к Django-style) и имплеменчены без буферинга (см. п. 2)
4) Если ваш фреймворк диктует вам одну конкретную прошитую javascript-библиотеку — подумайте дважды. Для intranet приложения это может сработать. Для публичного — я бы взял другой фреймворк. GWT вроде используют в паблике, но я лично с ним не работал.
5) Если к сервису понадобится REST Api, возьмите сразу фреймворк, в котором это есть, а не надейтесь на авось.

В целом так. Дадите больше требований к приложению — могу посоветовать что-то более конкретное.

www.mista.ru/links_1c.htm
здесь ответ на ваш вопрос.
Волшебный форум действительно рулит :)