SMiX
+3
Тут зависит от подхода. Иногда целесообразно начать с дизайна(читай интерфейса), а иногда — с программной части. Зависит от проекта и принципов работы.
Getting Real начинает с интерфейса, с реальных экранов, которыми будут пользоваться ваши клиенты. Это позволяет получить правильный интерфейс до того, как вы создадите неправильную программу.

© Getting real
SMiX
0
Сейчас уже позволяют, как я уже писал выше, через HTML5 history. Правда, в пределах текущего домена.
SMiX
+8
HTML5 history избавит веб от этих проблем.
Уже успешно применяется на гитхабе в репозиториях и, прости господи, вконтакте.
SMiX
+15
А пусть принимают. Сами захлебнутся от регистраций =)
SMiX
+1
1. А как вы в случае, если во втором поле хранится, например, JSON, сделаете выборку по одному из полей этого JSON'a? И это самый простой пример.
3. В той же CouchDB из коробки есть веб-админка, в которой можно смотреть как сами коллекции, так и их view-функции.
SMiX
0
Навряд ли в ближайшее время появится такая NoSQL, которая способна всю логику работы с данными держать у себя, а клиентскому приложению отдавать уже только сформированные данные.

А как же map/reduce в MongoDB и CouchDB?
SMiX
0
Я думаю, перепишут на джанге. Зачем им пицца из проектов.
SMiX
+3
ebay на java, кстати.
SMiX
+1
Да здесь и без облаков реально.
Триалки ведь умеют отключаться по истечении фиксированного срока. Ничего не мешает этот срок импортировать из ключа, например, или данных из АппСтора.
SMiX
0
А лучше сдавать приложения в аренду.
SMiX
0
Добавлю еще к последнему абзацу Scala и Lift framework для нее.
SMiX
0
И продолжают использовать, потому что слишком долго, дорого и сложно сейчас что-то менять. странный аргумент.
SMiX
0
php там сейчас, грубо говоря, используется для того, для чего и задумывался — в качестве шаблонизатора.
SMiX
0
Которые сами признают выбор php неудачным.
SMiX
0
Не очень полезно на коленях сидеть. Может развиться варикоз.
SMiX
+2
Потому что php не всегда лежит в /usr/bin
SMiX
+1
Сервер для оперирования социальными графами тоже написан на Scala ( github.com/twitter/flockdb )
SMiX
0
Ну да, я ошибся, сказав про «область функционального программирования». Новичок в этом.
SMiX
+1
А там есть средства для параллельного программирования — такие как процессы Erlang или akka(построенная на Actors) для Scala?
SMiX
0
Кто-нибудь успел поработать со Scala и Erlang и сделать для себя выбор?
По-моему, это сейчас два главных конкурента в области функционального программирования.
SMiX
+1
Главное, чтобы на разных доменах не слетала авторизация.
SMiX
0
Ну разумеется не имелась в виду полная замена фотошопа. Просто некоторые вещи можно сделать без него.
Например, скругленные углы или вертикальный текст только лишь средствами CSS3.
SMiX
+9
Делается очень просто на git hooks. На любом языке можете написать хук.
SMiX
0
Вот, где css-фреймворки — это добро. Можно инклудить их стили, а на выходе получать человеческие и идеологически правильные названия классов.
SMiX
0
x86_64?
SMiX
+5
Посмотрите foxyproxy
SMiX
+1
Ну, опять же, в руби не принято «скачивать» библиотеки. Они могут быть, например, в закрытом репозитории, но в виде rails-плагина или gem'a, чтобы в проекты подключать их одной строчкой, управлять версиями, зависимостями.
SMiX
+2
Необходимо.
Для руби библиотеки в 90% случаев поставляются в виде rubygems. В противном случае вас просто не найдут(через тот же gem search -r %keyword%)
SMiX
+1
Да и не только из-за скорости и утечек памяти.
Среди причин плохая расширяемость.
SMiX
+2
Тот же phpclasses.org и pear/pecl не сравнятся с rubygems. До руби я много и писал на php, и мне есть с чем сравнивать.
SMiX
0
Явно, вы не пробовали действительно работать с ними на языках помимо php(если говорить о вебе).
SMiX
0
Эти библиотеки рождаются благодаря качествам языка.
SMiX
0
Эта черная кошка а) гуглится на раз б) для руби есть каталоги расширений(rubygems.org, ruby-toolbox.com). не знаю, как в питоне.
SMiX
0
… и при этом на настройку уходит не больше десяти минут, есть поддержка авторизации как минимум тремя методами(включается одной строчкой конфига), за считанные минуты можно прикрутить openid/oauth/fbconnect
SMiX
0
А вот как раз у вас больше шансов где-то ошибиться, реализуя вручную, например, авторизацию вместо установки того же devise, которым пользуются и который тестируют тысячи пользователей.
SMiX
0
Не увеличиваются.
Для этого кода все так же написаны тесты, у него много пользователей, и он так же активно развивается силами сообщества.
SMiX
+3
FaceBook сами признали, что php они выбрали зря. Если хотите, кину пруф на конференцию.
SMiX
0
Да какая все-таки разница, кто реализовал fastcgi: авторы языка или его пользователи?
SMiX
0
Профита не вижу ни для себя, ни для, тем более, заказчика, что ему есть за что переплачивать хотя бы за хостинг/администрирование vds.
Скорость и качество разработки.

А хостинг, как уже сказали, можно сделать и бесплатный(GAE для Django или Heroku для Rails)