Сергей Еремин

Ответ не будет, пока не ясно какая нагрузка. Свой сервер -- дорогая игрушка (учите, что надо будет платить на юнит в стойке провайдера, порты, IP-шники, питание. Все это "постоянные издержки" которые стартапу всегда надо минимизировать. Когда проект будет в плюсе по "переменным издержкам", то уже можно смотреть как избавившись от некоторых из них, и переложившись в "постоянные издержки" сэкономить. Так что садитесь на виртуалки или комбинацию сервисов Amazon и вперед.

Через связь многое-ко-многому, где в таблице связей кроме ключей есть поля с нужными характеристиками (например, число предметов в связке-наборе, или линк на таблицу с дополнительными характеристиками).

Через jQuery. Получить куку:
var cook = $.cookie("citi");
Установить куку (с временем жизни 10 дней):
$.cookie("citi", "Moscow", { expires : 10 });
Можно куки и через мета в HTML-е установить

<META HTTP-EQUIV="SET-COOKIE" CONTENT="name=имя;expires=дата; domain=имя домена;path=путь;secure">

И вообще погугли. Примеров масса.

Не ясно. В описании кейса не хватает данных. Нужно понимать механику коммециализации.

Одно дело, если то что спрограммировано надо бегать продавать, обучать клиентов этим пользоваться, договариваться с поставщиками данных-контанта-трафика и пр. ... И другое, если спрограммированна машинка для печатания денег, которую запустил и она сама-себе работает и капает сиротской денюжкой...

Научиться плавать можно толь бултыхаясь в воде и периодически глотая воду. :) Программирование тоже нельзя изучить просто читая книжки. Придумай себе проект и стругай. Попутно изучаются HTML, CSS, JavaScript, JQuery, администрирование серверов и пр.

Главное быть внимательным к деталям! Не забывать рефакторить уже написанный код при получении новых знаний и понимании новых концепций... а еще поддерживать единый стандарт всего-всего-всего в своем проекте. Внимание к мелочам -- главное, что отличает говнокодера от программиста.

А вот присоединятся к чужому проекту думаю будет ошибкой. Слишком много концепций и деталей придется усвоить разом. Это все равно что подтянуть английский язык сразу посетив конференцию биологов-микрохирургов. Вроде на английском все разговаривают, но все равно не понятно о чем.

Мне нравится dbForge Studio ... в нем схемы получаются вполне разумные. Но он он только для MySQL :(

А как-нибудь иначе, например прям из брокерского терминала не проще брать котировки? Многие дают с радостью, только попроси.

Вопрос философский. Это примерно как солить во время готовки, или в конце пусть каждый солит в тарелку... Но, на самом деле есть разница. Если нужен обычный сайт, то заказчикам проще посмотреть на картинку еще до начала верстки. Им так удобнее. Кроме того, такой подход органично вписывается в этапность сдачи работ, а ведь сдавать работу и получать оплату этапами приятнее для исполнителя и спокойнее для заказчика. В случае если это незатейливый сайт, этап прототипирования ведь отсутствует, так что сдача дизайна, акт о заверении этапа работ -- вполне себе рабочий вариант.

Постучись в сообщество postgresql-истов.
https://www.facebook.com/groups/postgresql/
Они правда апологеты другой религи, но помогут.

P.S/ Имхо, можно руками. SQL-файл текстовый. Если там не очень наворочено с индексами и связями, то возможно достаточно типы переменных в таблицах поправить.

Зависит от того кто будет поддерживать и допиливать. Если сам -- то пиши с нуля. Если отдавать на аутсорс и чтобы можно было передать после кому-то еще -- то ощущение что Drupal подойдет. Там со всякими голосовалками за рейтинг, множественной атрубутикой и пр. -- хорошо все.

• Платные наборы иконок picons.me.
• Неплохой, универсальный набор entypo.com.
• Несколько универсальных наборов с поиском thenounproject.com
• Более 1000 пиктограмм в PNG и WEB-шрифтах webhostinghub.com

Мучаюсь аналогичным вопросом... Но придумал себе несколько проектов и пилю по мере сил. Есть даже шанс, что один из них даже доход потенциально даст. Участники рынка, для которых я его выпиливаю кивают головами, говорят, что полезная со всех сторон штука, и будут ее пользовать и платить, если она заработает.

Странный вопрос. Зачем учитывать книги? А если книгу прочитал несколько раз (бывает и такое)? А если книгу прочитал в детстве, а вот сейчас перечитываешь и осмысливаешь иначе? А настольные книги, которые вроде и не читаешь, но пользуешься постоянно (справочники, энциклопедии, руководства)? А еще есть журналы с вполне умными статьями требующими осмысления (не поверите, но аналитические статьи по экономике периодически хочется перечитать года через три и даже десять... сравнить циферки и проверить реализацию прогнозов)? А еще есть литературные журналы, которые вообще ничем не хуже книг.

В электронных читалках все легко учитывать. Там даже метки-маркеры и заметки к выделеням можно делать и систематизировать. Кроме того это можно делать с разных устройств, т.к. все читаемое хозяйство в облаках...

Скорее всего ДЦ спрашивает паспортную мощность. Т.е. сколько максимум питания будет потреблять оборудование. Убедить ДЦ, что сервер будет потреблять 350VA, при паспартных 800VA в любом случае будет очень сложно.

Собственно уже при расчете, могут учитывать и фактическое потребление. Но это далеко не у всех ДЦ есть… Например, в нашем ДЦ тарификация c замерами фактического потребления по запросу. Но еще никто не запросил. :)

если записей и тегов много, то SQL будет тормозить. Запросы тяжелые, кешируются слабо (особенно если строить облака не по календарным месяцам, а по минус-N-дней-от-текущей-даты). Собирать и облака тегов ежемесячно (еженедельно, ежедневно… как там у вас в задумке), формировать из них статичные структуры (HTML, например) и отдавать по запросу.

Блин… что за советы… там есть встроенный класс: navbar-fixed-bottom

<div class="navbar-fixed-bottom row-fluid">
      <div class="navbar-inner">
          <div class="container">

ТУт вот уже целый автомобиль (все корпусные панели) печатают…
www.cadpoint.ru/news/1-latest-news/672-presented-the-first-car-designed-by-3d-printer.html
При печати корпуса фар будут узкие места — ушки крепления. При наших перепадах температур может не выдерживать, т.к. в местах крепления значительные вибрации возникают. Ведь при печати микроструктура пластика иная чем при литье… Возможно, надо напечатанное тепловой обработке подвергнуть… Улучшить микроструктуру… Надо ставить эксперимент.

Заработает. Даже 32Гб заработало бы если бы были такие димы. По опыту работает даже совершенно дикие комбинации а тут почти штатный режим. Главное убедитесь, что тайминг памяти правильный. Иногда более быстрые Димы не работают на медленных машинах (хотя должны были бы)