Pull to refresh
4
0
Send message
Я бы сказал, что доклады ни о чем, только у Юры более менее что-то приличное и полезное, все остальные для галочки.
Я так понимаю эта тема пришла из rubyonrails-talk, но там на неё даже внимания не обратили. Возникает ощущение, что у автора проблемы с чтением и умением гуглить, не нашел method_missing — это просто смешно. Есть отличные книги и по руби, и по рельсам, после прочтения которых все становится намного легче. У каждого языка есть свои особенности, и, обладая достаточными базовыми знания, можно покрывать недостатки документации чтением исходников, так как руби, по сути, очень хорошо читаемый язык. Да, может быть, для человека, работающего с пхп, это не совсем привычно, но мне это даже нравится, узнаешь много нового и полезного, и в дальнейшем это окупается. А если такой подход не нравится, то лучше в руби даже не лезть, но если очень хочется, то уж удосужься потратить хотя бы пол годика на изучения языка, все приходит с опытом.
В целом, мне нравится текущая ситуация, и я не очень хочу ещё большей популяризации языка, ни к чему хорошему это не приводит. Рельсы опопсели, растолстели и превратились в ужасного монстра… но это терпимо.
Спасибо автору за перевод статьи из официальной вики девайза, правда, конечно, отличия есть, например, вместо скафолда использовал бутсрап, ибо это сейчас модно. Но зачем это все не совсем понятно, в реальной жизни требуется привязка к одному аккаунту, и это более показательно и интересно. Для того чтобы оставить коммент, можно использовать виджеты, там и социальность сразу.
И, кстати, create! тут по мне не уместен, он просто вызовет RecordInvalid, что приведет пользователя к 500 странице, можно и нужно использовать create или find_or_create_by_url или first_or_create, тем более что дальше идет проверка на существование записи.
Есть ещё один вариант хранения переменных авторизации, это просто хранить их в переменных окружения системы, тогда не нужны файла, которые все равно желательно включать в репо.
Есть просто правило: все статические строки, если они используются в коде не один раз, загонять в символы. Получается небольшой дополнительный расход памяти взамен на небольшой прирост производительности, так как символы сравниваются намного быстрее.
да я тоже подвис на этой фразе)
1) конечно, он практически бесполезен, но в данном случае использовался для упрощения задачи, так как формат сообщений строго задан (в реальном приложении можно использовать протобуферы, json и т.п.)

2) Да, если убрать, то фактически ничего не изменится, но читаемость кода снизится. А так проще будет организовать фолбек на случай потери коннекта (например, трабла с таймаутом соединения с mysql) и т.д. и т.п.

3) Код писался пару часов, я дольше писал эту статью), да и смысла особого не было доводить до конца, так как писал фо фан. + Цель была просто показать, как можно тестировать такие приложения.
Ну, в принципе и этот код можно ужать строк до 40-50, что вернуло бы его к изначальному виду, просто цели такой не было.
И я не спорю, что ffi полезен))
На самом деле, все зависит, от того, что вам необходимо и от ваших предпочтений. Я лично не пользовался node.js, так как код на руби мне кажется намного красивее. Из очевидных преимуществ — это попсовость node.js, что означает больше поддержки, чаще обновления и т.д. и т.п…
спасибо, исправил.
да, так и есть, в последнее время очень мало чего на русском читаю.

Information

Rating
Does not participate
Registered
Activity