HaruAtari: В руби одно и то же делается многими способами. Хочешь ставить скобки - ставь, не хочешь - не ставь. Этот странный тип "символ", хотя вроде существует интернирование строк... Способы объявления хеша ( :sym => "value", sym: "value" или того круче sym: :value)... Короче, я вынужден согласиться, что в этом что-то есть, тем более что в рельсах руками вообще мало что нужно делать - все за тебя гемы делают, но так же я понимаю, что это не мое. Уж лучше бы на пыхе было что-то настолько же крутое, как рельсы... Но на пыхе этого нет, поэтому у ROR нет действительно достойного конкурента.
Node.js, Rails (почему бы и нет), PHP. Лично на мой взгляд остальное не стоит внимания, потому что весь спектр задач в вебе (а ты же, я так понимаю, вебом решил заняться?) решается этими языками. Отдельно по каждому:
1) Node.js - пожалуй, одно из самых активно развивающихся направлений, которое в ближайшее время взорвет всю область веб-разработки (возможно, и не только веб). Силен своим асинхронным подходом.
2) ROR - на нем разработка будет очень быстрой, так как есть гемы на все случаи жизни и четкая структура приложения, что позволяет эти гемы безболезненно внедрять и почти ничего не писать ручками. Вряд ли ты будешь понимать, что там на самом деле происходит под капотом, но оно будет "просто работать".
3) PHP - самый доступный язык. Не думаю, что стоит юзать его непосредственно, но для очень широкого круга задач есть готовые решения типа вордпрессов, битриксов и прочих друпалов. Как язык он ничем не хуже руби или питона. Если смотреть на фреймворки, то вряд ли там есть что-то объективно лучшее, чем рельсы. Хотя сильно зависит от конкретной задачи.
P.S. Все это чисто мое мнение, основанное на моем же опыте, и я никого не призываю холивару.
Максим Антонихин: Ну если ты его просто используешь по назначению и не пытаешься выполнять запросы минуя модели, то скорее всего ты делаешь все правильно. Другое дело, что ты не знал о его существовании, когда его использовал, но тем не менее)
Роман: да не, в рельсах ваще знать ничего не нужно) достаточно вбить в гугл rails gem {{сюда функция, которая тебе нужна}}, найти решение, добавить гем, сгенерить модели, контроллеры и вьюхи, написать пару строк и оно как бы уже работает. Пес его знает, как, но работает) А в ноде пока да - многое ручками делать нужно. Это даже не столько касается sails, сколько ноды в целом.
Ну да, у меня примерно те же ощущения. А про rails зря так говоришь - он наоборот прост до безобразия, там вообще почти код писать не надо - все где-то далеко под капотом за тебя сделано ("магия" rails). Меня на самом деле это и отпугнуло - хочу полностью понимать, что и как работает.
Посторонним В.: может если скобки расставить, то получится. Возможно, тут сначала выполняется tmp::CONSTANT, потом $object -> ... Стоит попробовать ($object -> tmp)::CONSTANT. Не уверен, но может сработать.
Babel я лично не использовал, но предполагаю, что его можно с watch интегрировать, то есть просто складывать или в ту же папку скомпиленный файл, или вообще разделить папку с самим проектом и его кодом на es6. Ну это только предположение, может я неправильно понимаю работу babel)
Express в sails вроде остался судя по package.json. Может, это они не убрали просто, но судя по объектам request, response он там должен быть.
Waterline независим от конкретной субд, плюс у него киллерфича - полностью прозрачные миграции на реляционных базах, взаимозаменямость реляционных и не реляционных. Теоретически можно использовать, например, монгу в разработке и постгрес в продакшене - разницы с точки зрения логики приложения никакой, только адаптер нужный подставить надо в конфигах.
Вот изоморфный код - это да, наверное, было бы проблемой прикрутить к sails. А вот REST API там можно даже без контроллеров лепить с помощью blueprints - можно просто создать модели, задать им всю логику проверок, преобразований значений и т.д. - и все, приложение готово можно сказать) Возможно, подобное есть где-то еще, но я с этим впервые столкнулся в sails.
Иван: ну так я и предлагаю решение проблемы - автозаполненное поле с возможностью изменить e-mail. Вводить в простейшем случае ничего не надо, только нажать на одну кнопку для отправки формы и все. Такой компромисс для решения ряда проблем, на мой взгляд вполне оправданный.
Иван: возможно, на coub как раз значит openapi используется (или раньше использовался, когда я там через контакт регистрировался) - там у меня почту спросили. В VK я, видимо, scope как раз не прописал, так что мыла там в данных пользователя не появилось (в ФБ и твиттере есть) - надо будет попробовать.
А почему бы не спросить пользователя e-mail? Просто, как я и написал, вставлять в поле по умолчанию мыло от провайдера, а если надо, то пользователь изменит.
На хабре я когда-то в личном кабинете уже после авторизации привязывал соц. сети, было такое. Правда, до перехода к единой TM-учетке.
Я не говорю, что пользователь не должен раскрывать e-mail - я говорю о том, что он может быть не тем, на который зареган акк у данного провайдера. У меня, например, есть почта "для спама", "для работы" и личная) Естественно, сайту я бы скормил почту для спама, хотя в Facebook я зарегистрирован по личной. И мне либо отказываться от авторизации через фб, либо получать спам на личную почту отовсюду, где я зарегистрирован. К тому же как быть, если уже есть учетка, я нажал на вход через, скажем, VK и получилось, что у меня 2 аккаунта? Объединить их уже не получится. А если спросить почту, то можно будет указать ту, которая уже зарегистрирована на сайте, увидеть сообщение, что я уже тут есть, авторизоваться по паролю и привязать аккаунт.
Павел Громадчук: но тем не менее учесть сценарий, что пользователь не хочет раскрывать свой e-mail по определенным причинам, тоже нужно на мой взгляд. Учитывая еще тот факт, что у многих почты могут отличаться. А подход с идентификацией по uid вместо e-mail позволит справится с этой ситуацией.
Ты readme почитай, там в частности указан порт по умолчанию (35729) и прочие настройки. То есть тебе при настройках по умолчанию просто в шаблоне нужно подключить
Ну не знаю, я вообще чистый npm использую для стилей и скриптов (blog.keithcirkel.co.uk/why-we-should-stop-using-grunt - вот статья, после которой я решил больше не пользоваться таск-менеджерами), без grunt и чего-то подобного - это вообще не проблема в sails. Просто при создании приложения добавляешь --no-frontend и удаляешь папку tasks с gruntfile, а дальше делай что хочешь.
Babel вообще вроде просто js файлы компилирует в ES5, ему ж должно быть без разницы, что используется, разве нет?
Вообще sails ничего не навязывает особо, только дает структуру и базовый набор всего необходимого, где любой компонент можно легко заменить или вообще убрать. В принципе все то же я бы делал на Koa или чистом Express, но это бы отняло много времени.
Константин Китманов: sails просто сразу дает то, что необходимо - конфигурации, сессии, сокеты, структура приложения... Короче, то, что или ты будешь делать вручную, или возьмешь sails. Разницы по сути никакой, а определенная экономия времени имеет место. Другое дело, я некоторые вещи выпиливал из sails, так как не люблю, когда много лишнего, но все равно оказалось быстрее)
Константин Китманов: ну в общем сейчас опробую ноду с sails на реальном проекте, посмотрим, что из этого выйдет. Все равно пока я этого не сделаю - понять не смогу)
Думал, может на тостере есть кто-то, кто может опытом поделиться, но видимо всем страшно) А я или храбрец, или дурак - посмотрим.
Константин Китманов: а waterline как же? С другими дела не имел, но waterline пока для меня выглядит вполне прилично. Пока не Rails ActiveRecord, но sails вроде активно развивается и waterline вместе с ним.
Константин Китманов: ну это да, вряд ли модулей под sails больше, чем гемов. Но там же абсолютно безболезненно можно использовать любой плагин npm, а их количество, думаю, уже сравнимо с гемами (могу ошибаться).
А по обкатанности да, сейчас любая платформа обкатаннее, чем sails)
Константин Китманов: так а в чем принципиальное отличие sails от того же rails, что он не в почете? По простым сайтам - конечно, там проще движок взять, в этом согласен.
bogolt: так мой ответ нисколько этому не противоречит. Я показал самый очевидный вариант ошибки. Естественно, за методами доступа должна стоять какая-то логика проверок, преобразований и т.п., иначе это не имеет смысла. А такая логика хотя бы на минимальном уровне должна присутствовать в подавляющем большинстве случаев. В остальных же случаях я бы все равно сделал так же просто для того, чтобы сделать все однородным, так что даже твой вариант кода может быть применим.
А интерфейс - это вариант полиморфизма, и внутренняя кухня тут значения никакого не имеет, поскольку код, который использует объект класса, реализующего интерфейс, не может иметь представления о том, что в объекте есть помимо собствтенно реализованного интерфейса.
