IgorStepin

Не стоит.

Мне кажется, что хорошим критерием будет готовность нанять отдельного человека на Kubernetes. Пока такого человека нет переходить на него не стоит. При этом собственный код можно понемногу готовить к нему (метрики Prometheus, запуск в контейнерах и тп).

А вот если вы видите, что тратите кучу денег на облака и хочется сэкономить, перейдя на bare-metal (арендованный или свой), то тут Kubernetes как раз и пригодится.

Я бы и swarm не использовал. Можно же просто systemd-сервисы для контейнеров и какой-нить Ansible. Будет максимально железобетонно.

У меня не принимало из-за тире в адресе. Убрал -- и оно переформатировало введенные значения под свой вид.

Мы сделали на базе модуля https://github.com/pgaertig/nginx-big-upload , т.к. нужно было не просто загружать файлы, а загружать большие файлы с возможностью докачки. Если без докачки, то и clientBodyInFileOnly сойдет.

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

Разработка в БД даже после установки/настройки/адаптации окружения для разработки все равно дольше, чем разработка обычных программ. Так же появляются дополнительные архитектурные ограничения. Единственный плюс — это увеличение скорости сложных выборок.

Есть еще code.google.com/p/substruct/

Аналоги rails-shared-хостинга есть (dreamhost.com и locum.ru, например), есть совсем специализированный heroku.com (больше уже облачный). Так что какой-то спрос на это есть. Сможете ли его продать именно вы — второй вопрос, не для этого сайта.

Осознать чему нужно учиться. Например:
1 Оценить какие проблемы были на 3х последних проектах и какие знания помогли бы это избежать
2 Какие еще инструменты можно изучить (от vim до специализированных тулзов для профилирования). Сюда же и горячие клавиши к используемому IDE
3 Изучить аналогичные современные библиотеки и фреймворки, возможно, что ваши подходы уже не так эффективны
4 Изучить перспективные библиотеки и фреймворки, которые вскоре могут понадобиться
5 Изучить принципиально другие языки программирования, например Java/PHP/Ruby(Python)/Erlang/Haskell. С языками идут свои концепции и даже на основном языке ваш код улучшится
6 Если про веб-разработчиков, то даже среди людей со стажем 5-7 лет мало встречал, кто бы действительно знал Javascript и SQL одновременно хорошо, как правило, одну из этих вещей можно подтягивать и подтягивать. SQL еще может делиться на MySQL, PostgreSQL, MS SQL, Oracle SQL. Желательно знать первые 2 хотя бы (особенно при непонятках с будущим MySQL). + различные NOSQL
7 Вернуться к истокам (Кнут, алгоритмы, паттерны). Особенно паттерны хорошо читаются после некоторого опыта.
8 Что-то из смежных дисциплин (управление проектами, дизайн пользовательского интерфейса, маркетинг, архитектура сложных систем)

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

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

Наверное, уже поздно, но все же: railscasts.com/episodes/124-beta-invitations

Если серьезно, то класть в CDATA или не использовать jspx:

<![CDATA[&nbsp;]]>

На самом деле, проблема на этом уровне нормально не решается. Если просто неудобно для отладки, то смотреть через firebug и подобные штуки (кстати, насколько помню, кто-то из браузеров, вроде бы Опера, форматирует сам перед отображением исходников). Если пробелы требует верстка, то верстать, чтобы не требовала или вставлять nbsp.

Немного изучал этот вопрос и пришел к выводу, что человеку писать jspx нет особого смысла, удобней jsp (nbsp, условные комментарии для IE, javascript и знак меньше, сохранение форматирования и проблелов, ...). Только для генерирующих и обновляющих утилит удобно, т.к. они могут работать с деревом xml.

Вы уверены, что соединение оборвется с ошибкой? Если Линукс, то он открытые файлы (например, видео) после удаления продолжают работать (проигрываться, до закрытия файла, видимо), насколько помню. Так что, возможно, проблемы просто нет.

Если значительно допиливать, то нужно брать не CMS, а фреймворк любой стабильный и знакомый, и на нем делать. Как расширять CMS лучше спросить у создателей CMS, у них должны быть отработаны варианты (хотя цифра 0.1 не наводит на оптимистичный мысли на этот счет :) ). Хотя, в целом, примерно так, просто конкретные файлы и схемы работы будут у разных CMS разными.