vsuhachev

Ответ на вопрос "почему" заключается в одной емкой фразе: потому что сложно синхронизировать интерфейс и состояние.

Представьте, что у вас есть простой UI какого-нибудь ToDoApp. Вам всего-то нужно сделать так, чтобы при вводе новой задачи она появлялась в списке, а при нажатии на крестик напротив удалялась бы. Проще простого!

Но когда начнете решать проблему на нативном JS или на б-гомерзком jQuery, вы столкнетесь с необходимостью писать очень много шаблонного кода. Прежде всего на обслуживание DOM. Найти элемент, вставить элемент, добавить элементу класс, атрибут... в итоге у вас получится портянка на десятки строк для такой элементарной задачи, а ведь мы еще не добавили много кульных штук, без которых ToDoApp совсем не ToDoApp, как-то: возможность создавать разные списки, расписания, галочка, чтобы зачеркивать задачу и т.п. С реализацией всего этого ваша простыня будет расти, вы будете в ней путаться.

На этом этапе вы можете начать велосипедить. Писать какие-то утилиты для работы с DOM. Разделите index.js на несколько файлов, сообразно DDD или хотя бы единой ответственности. Допустим даже, что вашим приложением внезапно стали пользоваться, у вас куча бизнес-идей. Вы начинаете наваливать фичи, структура становится все запутаннее, кода становится все больше, а еще приложение начинает тормозить. Вы проводите небольшой анализ и понимаете, что проблема в излишне частом обращении к DOM - вы дергаете его на каждый чих, ведь с jquery это так просто! И что делать? Писать еще один велосипед, чтобы обновлять DOM пакетно? А как отслеживать изменения в данных с сервера? Это ж сколько работы!

К счастью, все вышеописанное, и даже гораздо больше, уже решено в Google, Facebook, а также некоторыми талантливыми энтузиастами. И у нас есть Angular, Vue, React, Svelte, которые предлагают вам возможность создавать быстрые, поддерживаемые приложения с минимумом шаблонного кода и продуманной архитектурой.

Кстати еще очень немаловажное замечание:

* xen/vmware/virtualbox/kvm — умеют работать только с контейнерами, т.е. хост система не монтирует диски гостевых контейнеров (но может это делать через снапшоты, например) — значит хостер имеет ограниченный доступ к данным своих клиентов. Так как для этих технологий вполне возможно создать свою виртуальную машину, со своим ядром и загрузчиком initramfs, тру параноики создают шифрованный контейнер, а пароль вводят через ssh в initramfs. Для получения доступа к данным такой машины потребуется чуть больше чем просто права администратора (в простом случае необходимо будет изучать дампы памяти, а в сложном — потребуется специализированное железо и много много денег)

* openvz/lxc/chroot — файловая система виртуальной машины должна быть примонтирована в хост системе, шифрование файлов и т.п. фактически недоступно (защитить данные от хостера нереально сложно, но можно поиграться с каскадированием виртуальных машин)

Доступ хостера к данным — очень важный момент для некоторых проектов (здравствуй провайдер linode и украденные много много bitcoin, послужившие теоретически основной причиной смерти сервиса bitcoinica).

bulk_insert или activerecord-import

Решал такую задачу с помощью прекрасной библиотеки: https://github.com/rubysolo/dentaku
Умеет парсить математические и логические формулы, кодставляя динамические значения переменных.

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

На чистом JS - у браузеров уже давно есть fetch api:

fetch('http://country.io/names.json')
  .then(r => r.json())
  .then(names => console.log('Names arrived!', names)

Узнать больше можно из документации:

• https://developer.mozilla.org/ru/docs/Web/API/Fetch_API
  
• https://developer.mozilla.org/ru/docs/Web/API/Fetc...
  
• https://developer.mozilla.org/ru/docs/Web/API/Response
  

Ну и про CORS не забывайте - если сервер не вернет эти заголовки, то запрос на другой домен не пройдет.

Это потому что вы просто тупо пишете код, а вам нужно разрабатывать (проектировать) приложение.

Как я перевел свои домены к другому регистратору и продлил 2 домена не за 800 рублей, а за 200.

Сейчас в 2domains стоимость продления 399 рублей, продление 2 доменов за 798 рублей совсем не радовало.

В итоге перевел на regname24.ru, там стоимость продления также 99 рублей.
У одного домена уже вышел срок регистрации, но он еще не был освобожден (месяц не прошел), до конца регистрации другого домена оставалось 4 дня.

regname24.ru является реселлером у 2domains, надо написать в 2domains , чтобы они перенесли домены к regname24.ru, потом написать письмо regname24.ru и домены появятся.

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

Если что спрашивайте.

Таким образом я сэкономил 600 рублей.
Хостингом пользуюсь Радиусхост, тоже доволен, стоимость в год всего 950 рублей. Искал дешевле, но они все какие-то не такие, если дешевле.

Есть лучшее решение: gem https://github.com/romiras/rails-translate-routes
Gemfile:

gem 'rails-translate-routes', git: "https://github.com/romiras/rails-translate-routes.git"

позволяет хранить локализованные пути в файле config/locales/routes.yml

en:
  routes:
    # you can leave empty locales, for example the default one
es:
  routes:
    products: productos
    contact: contacto
    new: crear

а сами пути в коде остаются ясными

edit_product_es GET    /es/productos/:id/edit(.:format) {:action=>"edit", :controller=>"products"}

Есть множество ресурсов, наподобии https://railsbox.io/, которые позволяют сконфигурировать бокс под нужные задачи. Rubmine имеет интеграцию с vagrant в следующих составляющих
- Позволяет управлять контейнерами из заранее преднастроенной папки (up/down/provision/etc)
- Использование ruby SDK из vagrant
- Запуск и отладка rails-приложений
Папка с кодом шарится с помощью synced folder (https://www.vagrantup.com/docs/synced-folders/). В качестве Synced Folder на всех платформах предлагаю использовать nfs. В частности, для Windows есть плагин vagrant-winnfsd (https://github.com/winnfsd/vagrant-winnfsd). В общем-то все)

Я бы сделал span+span[contenteditable].

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

Чувак, учись гуглить на английском, а то ты тут весь тостер завалишь простейшими вопросами, которые гуглятся на раз-два. Я тебе помогу: rails how to decode url symbols

Из рельс в общем-то никак, т.к. изображения на продакшене должны отдаваться nginx'ом. У рельс есть настройка для продакшена, насильно отключающая отдачу статики

# Disable Rails's static asset server (Apache or nginx will already do this)
config.serve_static_files = false

Если вы всё же по каким-то соображениям отдаёте статику рельсами, что категорически неверно, то в ApplicationController можно сделать перехватчик эксепшена

rescue_from ActionController::RoutingError, with: :routing_error

и в нём проверять, урл картинки это или нет.

Еще есть java, go - они тоже очень популярны.

И на том и на том пишутся замечательные вещи!

Go очень просто использовать - практически как замена C/C++, только более быстр в разработке. Сильно набирает популярность, достаточно низкоуровневый, чтобы на нем писать системные утилиты и большие распределенные системы. У него есть минусы (дебаггер например), но и плюсов очень много (дебаггер редко нужен).

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

Что касается PHP - изначально язык создавался для простых проектов для WEB, как замена CGI, но вроде бы как вырос, появились объекты... Но, дальше WEB он не развивается.

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

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

Сам программирую на Python, C, Java, PHP.
Относительно неплохо разбираюсь в Ruby и Go, на уровне влесть в чужой проект и поправить ошибку.

Мои фавориты - Java, Python. Присматриваюсь к Go.