UseRifle

1) Не совсем понятно зачем вам вообще генерировать картинки нужного размера в момент обращения к ним. Обычно все варианты картинок генерируются в момент загрузки.

2) Если все же вам так удобнее, в любом случае в том месте где вы будите хранить картинки (и формировать их налету) вам придется писать некий код-предобработчик. Например, Nginx сначала пытается получить ассет, а если не находит, то передает управление программной части, которая и занимается формированием и сохранением картинки. Сразу после первого обращения к картинке она будет создана и Nginx будет сразу отправлять ее клиенту как готовый ассет, не передавая больше управление скрипту.

3) Никаких проблем с расшариванием изображений быть не может. В БД хранится только путь к ассету. Например /public/pics/flower.png. Поскольку вы сами программируете систему, как и на фронте, так и на бэке вы легко можете в константах задать конкретный путь к вашему CDN + установить свои правила формирования имен картинок.

Например:

В базе хранится только

/public/pics/flower_original.png

А дальше можно формировать на основе этого базового урла что угодно.

/public/pics/flower_8000_6000.png
/public/pics/flower_800_600.png
/public/pics/flower_80_60.png

Хранить в базе урлы ко всем вариантам картинок — это бред.

Я добавил эту штуку к себе на блог — оно не срабатывало ни разу на откровенно спамерских комментариях.
Насчёт альтернатив не знаю.

Вот моя короткая история. в основном я пишу на php.

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

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

У Ромы Комарова есть, по-моему, то, что вам нужно.

ок. нашел сам.
То, как я считаю дни согласуется с международным стандартом ISO 8601

Согласно иудейскому и христианскому календарям, основанным на Библии, воскресенье считалось первым днём недели. Он наступает после субботы, седьмого дня недели (Исх.20:10) в старых религиозных календарях. Христианство заимствовало порядок дней недели из иудейского календаря. В Римской империи первый христианский император Константин ввёл в 321 г. семидневную неделю и назначил воскресенье (день Солнца) первым днём недели и днём отдыха и поклонения.

В наше время в странах Европы воскресенье считается последним днём недели. Первым днём недели воскресенье является в США, Израиле, Канаде, некоторых африканских странах. В СССР воскресенье считалось последним днём недели. В некоторых европейских языках (в славянских, немецком, финском, исландском) название дня недели среда указывает на тот факт, что изначально среда была 4-ым днём недели, а не 3-им, как в настоящее время в европейских странах. Согласно международному стандарту ISO 8601, первым днём недели считается понедельник, а воскресенье — последним.

ZCE и ZCE-ZF — нафиг не нужны.
github — ваше лучшее резюме.

ru.wikipedia.org/wiki/Tz_database?

Думаю вполне справедливо будет предложить девелоперу те же условия что и инвесторам, ведь он инвестирует в проект свое время, которое не будет компенсировано ЗП, т.к. он рассчитывает на более высокую ЗП.

Если вы получили условно 100 рублей инвестиций, за 50% от стартапа, то видимо 1% стоит 2 рубля. Дальше посчитать не сложно.

Ну а вообще этот вопрос сугубо индивидуальный как сказали выше. Как договоритесь.

Попробуйте Komodo

Идея ничего не стоит, потому как для воплощения нужно постоянно(!) генерировать дополнительные(!) и сопутствующие идеи пачками, чтобы оно доползло до реализации. Нести личную ответственность.

Вот реально бесят такие умники «есть особо ценная идея, что же с ней делать». А с чего вы взяли, что идея не дилетантская из серии «2+2=4»? Единственный способ проверки — сделать, рискнуть ресурсами.

Вы думаете у тех, кто каждый день работает в каком либо бизнесе, имеет неиспользованные средства, идей нет? Идей есть, людей нет ответственных, нет времени контролировать.

Самый умный вариант — позиция «у меня идей нет, буду делать с удовольствием ваши». Денег дадут, ресурсы дадут и подскажут еще куда копать.

А с эпизодическими идеями… не льстите себе. Они скорее всего слабые. Генерируйте лучше идеи там, где ведется работа и не тратьте энергию на то, что не будет реализовываться.

Например, если сесть, целенаправленно проанализировать рынок мобильных приложений, то за вечер можно пару десятков идей придумать. И что теперь с ними делать? Да ничего с ними не делать.

в левой руке гвоздь, в правой микроскоп?

А чем вас MySql не устраивает, стоящий на всех хостингах, способоных держать указанный онлайн?

Сам сейчас учу потихонечку. Могу посоветовать:
— Ruby on Rails Tutorial на русском для актуальной версии 3.1(последняя глава) в котором вас протянут по всем этапам создания сайта
— Перевод официального гайда от какого-то из хаброюзеров.

SQL дает встроенную валидацию структуры данных за счет нормальных форм, индексов и т.п.
Проверка корректности данных, которую дает SQL, — важна для разработки. Если её не будет, то придется писать руками эти проверки.

NoSQL дает возможность не возиться с маппингом, а сразу сохранять данные целиком объектами в базу.
Но это ещё не всё, NoSQL решения обладают предлагают средства для удобного маштабирования.
А так же средства по обработке всего этого маштабного хозяйства. В частности MapReduce.
Если у вас много данных или много запросов, и есть какой-то частный случай по данным, то NoSQL решение может быть полезным.
Если нет, то цитирую одного из разработчиков Apache Hadoop. На одном выступлении он изрек: «Если данных не очень много, то не выёживайтесь и используйте обычный SQL».

Что использовать в конечной ситуации — смотрите сами. Каждый вариант обладает своими достоинствами и недостатками. А ещё хорошо бы знать о недостатках и превращать их в достоинства.

Macbook Pro, пусть с меньшими характеристиками, не хотите?

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

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

Прежде чем создавать что-то новое вообще, даже для портфолио — имеет смысл покопаться в чужих решениях. Взять образцовые продукты с открытыми исходниками, и попробовать понять, как они работают, что-то модернизировать и т.д.

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

Я на ваш вопрос ответа не знаю, его знаете только вы (просто ещё не осознали). Просто подумайте:
1. Чем ваш учебник будет отличаться от существующих?
2. Готовы ли вы потратить кучу времени на его написание, вычитку, подготовку иллюстраций, вёрстку?
3. Вы уверены, что не забросите это? Недоделанная работа — нехорошая вещь: силы вложите, а результата нет.

Остроумные ребята сбежались…