[ /tv/ /rf/ /vg/ /a/ /b/ /u/ /bo/ /fur/ /to/ /dt/ /cp/ /oe/ /bg/ /ve/ /r/ /mad/ /d/ /mu/ /cr/ /di/ /sw/ /hr/ /wh/ /lor/ /s/ /hau/ /slow/ /gf/ /vn/ /w/ /ma/ /azu/ /wn/ ] [ Main | Settings | Bookmarks | Music Player ]

No.31319 Reply
File: 09ada47cc534480953e43ce8182e0c6a_330.jpg
Jpg, 16.05 KB, 288×330 - Click the image to expand
edit Find source with google Find source with iqdb
09ada47cc534480953e43ce8182e0c6a_330.jpg
Ruby on Rails же.
Отписываемся кто ненавидит, кто пользуется, кто достиг просветления, да и просто графоманим.
>> No.31333 Reply
>>31319
Как это так?! Тред про рельсы, на на пикче рубин.
>> No.31334 Reply
>>31333
Но ведь тред про рубин на рельсах.
мимопроходил
>> No.31335 Reply
File: ruby_on_rails_logo.jpg
Jpg, 34.43 KB, 316×376 - Click the image to expand
edit Find source with google Find source with iqdb
ruby_on_rails_logo.jpg
>> No.31350 Reply
>>31319
А веб-разработка как-то относится к программированию?
>> No.31352 Reply
>>31350
веб это просто фронтэнд
>> No.31356 Reply
>>31350
Пойди в anywayanyday пособеседуйся на веб-девелопера, поймешь что таки да, относится.
>> No.31358 Reply
>>31350
Почему нет? Один шанса из четырех, что веб-разработку ты представляешь себе как установку вордпрессов. Два шанса из четырех, что ты занимаешься крадолепкой на джаве или сишарпе, но почему-то считаешь это более программированием, чем крадолепку на рельсах.

А на самом деле я не представляю, чем в основной массе занимаются программисты (которые не веб), поэтому бугурчу.
>> No.31359 Reply
File: anyway.png
Png, 23.36 KB, 816×151 - Click the image to expand
edit Find source with google Find source with iqdb
anyway.png
>>31356
Что-то в инетах пишут про недавний исход ЦэИксов у них, видимо что-то случилось.
>> No.31360 Reply
>>31358
> А на самом деле я не представляю, чем в основной массе занимаются программисты (которые не веб), поэтому бугурчу.
Повторюсь, веб это фронтенд. Для того же RoR можно запилить GTKшные вьюхи при помощи напильника и чьей то матери (но зачем, если можно открыть localhost в любом удобном браузере?). Модели конечно различаются (одно и многопользовательский доступ), а все остальное от платформы не зависит.
>> No.31361 Reply
>>31360
Но ведь РОР — это бекенд, не? Фронтенд это джаваскрипт.
>> No.31363 Reply
>>31361
Если быть точным, РОР это фреймворк, сочетающий в себе фронтенд (html, css, javascript, ВНЕЗАПНО хелперы на руби, которые генерируют предыдущие пункты) и бэкэнд (ruby). Как можно наблюдать, фронтенд имеет отношение больше к верстке и готовым решениям, а не к настоящему програмированию. Что делать на бэкенде - решать тебе. Хочешь - напиши решения расписания за вменяемое время (вот это задачка уж явно для истинного программиста). Хочешь - ограничься скафолдами к таблицам обслуживаемой приложением БД.
>> No.31364 Reply
>>31360
Дваждую вот этого >>31361.
> веб это фронтенд
С чего вдруг? Веб-сервис вполне себе полноценное программное решение из бэкэнда и тонкого клиента. Я могу делать всю работу и формировать статичный html на сервере приложений тащем-та веб 1.0 в пример. И все. Фронтэнда нет вообще. Есть тонкий клиент, интерфейс и бэкэнд.
>> No.31365 Reply
>>31364
в данном случае фронтендом будет являтся код страницы на html и его шаблоны, например. По моему, ты путаешь фронтенд и клиент. Фронтенд это в первую очередь интерфейс доступа
>> No.31368 Reply
>>31365
С кодом html-страницы согласен, а вот шаблоны (не стили) это как раз часть backend, по которой он собирает интерфейс.
Давай сойдемся на том, что фронтэнд это интерфейс и часть твоей логики, выполняющаяся на тонком клиенте.
В любом случае веб 2.0 подразумевает наличие backend и динамическое формирование, и с тем что веб это фронтэнд я не согласен решительно.
>> No.31369 Reply
>>31368
> С кодом html-страницы согласен, а вот шаблоны (не стили) это как раз часть backend, по которой он собирает интерфейс.
> По моему, ты путаешь фронтенд и клиент
>> No.31393 Reply
File: New-Canvas.jpg
Jpg, 76.70 KB, 1280×1024 - Click the image to expand
edit Find source with google Find source with iqdb
New-Canvas.jpg
>>31368
> веб это фронтэнд я не согласен решительно.
Я просто оставлю это здесь.
>> No.33262 Reply
Что прочесть, чтобы найти работу веб-кодером на руби на рельсах? С чего начать?
>> No.33264 Reply
File: image.jpg
Jpg, 290.78 KB, 850×942 - Click the image to expand
edit Find source with google Find source with iqdb
image.jpg
Какой вид кофе в старбаксе надобно заказывать чтобы найти работу руби-программистам? Алсо не будут ли смотреть на меня косо если у меня всего лишь ipad 2?
>> No.33265 Reply
>>33264
Очень, блядь, смешно, да.
>> No.33268 Reply
>>33264
Эспрессо. Лучше ipad mini, но и 2 файн ту, как заработаешь - купишь.
>> No.33276 Reply
>>33268
Разве не обязателен при этом тонкий ноут от мака?
>> No.33283 Reply
>> No.34598 Reply
>>31319
Няши, помогите пожалуйста.

Делаю по инструкции: http://webbackend.blogspot.ru/2012/10/nokogiri-ruby-on-rails.html

1. Добавляю gem 'nokogiri' в гемфайл
2. В консоли bundle install
3. В контроллере:

# для получения контента через http
   require 'open-uri'
  
   # подключаем Nokogiri
   require 'nokogiri'

И после этого получаю ошибку:

cannot load such file -- nokogiri

Грешил на косячное окружение по неопытности, но в том же https://www.nitrous.io что написали выше ошибка та же.

Щито делать та?
>> No.35205 Reply
File: fff36.png
Png, 21.35 KB, 651×272 - Click the image to expand
edit Find source with google Find source with iqdb
fff36.png
Читаю Ruby on Rails Tutorial, отсюда который:
http://ruby.railstutorial.org/ruby-on-rails-tutorial-book
И тут он предлагает устанавливать руби как на пикрелейтед через rvm. Говорит, надо указать путь к openssl? Где взять эту openssl и узнать путь к ней? И зачем она вообще тут понадобилась?
>> No.35208 Reply
>>35205
На rvm.io написано, что специальная фича rvm - autolibs ставит всякие либы и как раз перечислены именно те, которые Майкл Хартл в этом тьюториале предлагает ставить одновременно с Ruby - YAML и OpenSSL. Хартл раздаёт устаревшие советы? Но ведь вроде посвящено версии рельс, выпущенной летом этого года.
>> No.35384 Reply
>>33268
А могли бы и в самом деле расписать, как стать Ruby on Rails гуру.
Можно даже в стиле поднадоевшей многим пасты про Python.
>> No.35608 Reply
File: Zero.no.Tsukaima.full.159544.jpg
Jpg, 144.67 KB, 905×572 - Click the image to expand
edit Find source with google Find source with iqdb
Zero.no.Tsukaima.full.159544.jpg
Что-то не очень жив этот тред, попробую потыкать в него.

Пишу имиджборду (не велосипеда ради, а скилла для)
Когда создаётся новый тред, мне надо, что бы к нему можно было сразу же перейти по ссылке /доска/id_треда.

В routes.rb у меня есть такой код:
topics = Topic.all
  topics.each do |topic|
    @board = Board.find_by_id(topic.board_id)
    get @board.alias + '/' + topic.id.to_s, to: 'topics#show', id: topic.id.to_s
  end
%% Да, треды пришлось назвать топиками, потому Thread уже занят для многопоточности. %%

Код выполняется при старте сервера, но вот при добавлении нового треда, url, естественно, не создаётся.

Пока попробовал вот что (в методе create контроллера тредов):
        Rails.application.routes.prepend do
          get @board.alias + '/' + @topic.id, :to=>"topic#show", :id => @topic.id
        end
, и оно не работает.

Rails 4.0.0
Что делать, анон?
>> No.35659 Reply
>>35608
Уже решил проблему своими силами:
Rails.application.reload_routes!
Но, как я понимаю, тут есть проблема производительности. Жду предлодения по поводу того, как таки добавлять по одному маршруту, не дёргая их все каждый раз.
>> No.35662 Reply
>>35608
Зачем для каждого топика заводить по отдельному роутинг-правилу? Чому бы просто не сделать?
get '*board_alias/:topic_id'
>> No.35691 Reply
File: 1.jpg
Jpg, 120.20 KB, 1279×714 - Click the image to expand
edit Find source with google Find source with iqdb
1.jpg
>>35662
Няша, тысяча лучей добра тебе!
Ткнул меня носом ровно туда, куда мне нужно было.
>> No.35692 Reply
>>31319
Поставил remotipart, перестал запускаться WeBricks:
$ rails server
Could not find mime-types-1.25.1 in any of the sources
Run `bundle install` to install missing gems.
$ bundle show mime-types
/home/user/.gem/ruby/2.0.0/gems/mime-types-1.25.1
bundle install, bundle update, bundle update mime-types пробовал.
А ещё пробовал удалить Gemfile.lock и запустить bundle install.
Других советов гугл не дал, а те, что дал, не помогают. Выручай, анон!
>> No.35701 Reply
>>35692
Отбой. Оказалось, что четвёртые рельсы у меня работают под ruby 1.9.1 (кстати, так и должно быть?)
Сделал так: gem19 install mime-types -v 1.25.1, потом ещё пару гемов пришлось так же поставить, и всё заработало.
>> No.35776 Reply
Анон, а посоветуй какие-нибудь книги/туторы/сайты по рельсам для продолжающий. ruby.railstutorial.org весь прошёл. Теперь интересуют тонкости.
Например, у меня есть модели картинки и поста. Картинка привязывается к посту. Хочу создать такую форму, что бы в ней можно было заполнять поля поста, и картинку выгрузить. Но пока умею создавать только одну форму на одну модель. А надо одну на две модели.

Да, это всё тот же кун, что пишет имиджборду на рельсах.
>> No.35778 Reply
>>35776
продолжающих
self-fix
>> No.35779 Reply
--->

А почему вы все пишете на рельсах? Почему не на Node.js, например? Из-за Ruby? Тогда почему именно рельсы, а не EventMachine? Из-за MVC? А насколько полезен для вас этот паттерн? Вы пробовали какие-нибудь другие? Насколько хорошо знаете другие языки и фреймворки для них? Лучше ли рельсы, чем Twisted? Устраивает ли вас производительность Rails, потребление памяти? Вообще, писали на них нагруженные проекты, где всё упирается именно в производительность фронт-энда? Давно с ними работаете? Вообще, что не устраивает в рельсах, что нравится в других платформах? Почему на них не перешли - только из соображений трудности перехода или реально есть причины остаться на Rails? Планируете ли в будущем изучить что-нибудь другое? Мне правда всё это интересно.
>> No.35780 Reply
>>35779
Загорелся просто желаением изуть Rails.
Потому что стильно-модно-молодёжно, да и востребованность у него высокая.
Паттерн MVC мне хорошо знаком по Yii Framework, но не хочу больше PHP.
Про EventMachine никогда не слышал, спасибо - посмотрю, что за зверь.
С Twisted немного баловался, да и сам Python мне нравится не меньше рубина.
А по поводу "нагруженых проектов" реквестирую любые (англ. или рус.) теоретические материалы на эту тему.
Ведь фигурирует в каждой второй вакансии, и никто толком не может объяснить, что это значит, и как это делать.

Пишуший имиджборду кун.
>> No.35795 Reply
>>35780
> фигурирует в каждой второй вакансии
Не там ищешь.
>> No.35796 Reply
>>35795
А что не так с "высоконагруженными проектами"?
>> No.35827 Reply
File: PoYILbI.jpg
Jpg, 61.21 KB, 400×598 - Click the image to expand
edit Find source with google Find source with iqdb
PoYILbI.jpg
>>35779
Ок, если правда интересно, то вот моё анонимное икспертное мнение о Ruby on Rails.
Рельсы на данный момент (Rails 4) представляют собой наиболее совершенную реализацию архитектуры "запрос-ответ". Convention over Configuration, DRY - принципы, на которых основана философия Rails. Большое комьюнити, множество гемов именно под Rails, кодогенерация бойлерплейта, а чаще всего и полное его отсутствие. Если используется ActiveRecord, то очень легко генерить/писать миграции, да и сам ActiveRecord довольно продуманный. Сжатие ассетов из коробки. В общем, все типичные задачи во фреймворке уже решены, и это позволяет сосредоточиться исключительно на логике приложения, не отвлекаясь ни на что лишнее.
Ruby сам по себе - наиболее подходящий язык для создания всяческих DSL. Как следствие получаем Rails - няшный DSL для веба. В этом смысле никогда не будет настолько приятного в обращении фреймворка на питоне - просто из-за примитивности языка.
> Node.js
Про Node.js столько говорят, но мало кто по-настоящему на нем что-то разрабатывал. Отсюда полное непонимание того, для чего Node.js нужен. На Node.js конечно можно разрабатывать какой угодно веб, но он очень не удобен в стандартной ситуации, когда у нас "запрос-ответ". На RoR клепать приложения "запрос-ответ" в разы быстрее, чем на ноде.
Когда нужен запрос-ответ-ответ-запрос-ответ-... то здесь конечно же Rails бесполезен, потому что Rails никогда не будет уметь в websockets, потому что вся архитектура Rails плотно заточена исключительно под "запрос-ответ". А вот Node.js в вебсокеты очень хорошо умеет, и поэтому на нем лучше всего делать чатики. Справедливости ради следует заметить, что вот есть Pusher (http://pusher.com) и можно якобы делать чатики в облаке, но мне не нравится такой подход.
> EventMachine
Те же самые соображения, что и в случае с Node.js - надо понимать, какую ты решаешь задачу и соответственно выбирать инструмент. И тут проблема в том, что под Node.js куча модулей на каждый чих, и все они конечно же работают асинхронно. А что с EventMachine? Большинство ruby-гемов бессмысленно использовать с EventMachine, потому что они синхронные и толку в таком случае от EventMachine никакого. Нужны асинхронные версии всех гемов для EventMachine. А есть ли они? Ну, положим, вебсокеты есть, но этого мало: мне нужны будут асинхронные клиенты для различных БД - есть ли всё это под EventMachine?
Алсо, то что Node.js - офигительный хайлоад из коробки - просто миф, которым всем запудрили головы. Проблема высоких нагрузок не решается просто выбором фреймворка. К тому же node.js по-прежнему сильно течет.
> Устраивает ли вас производительность Rails, потребление памяти?
Да, устраивает. По своему опыту могу сказать, что важно научиться грамотно кэшировать. Ну и можно же масштабироваться в случае чего, разве нет? Задача же не в том, чтобы запустить веб-сервер на кофеварке, а в том, чтобы получить чистый, сопровождаемый и хорошо протестированный код, ну а железо масштабируется.
И советую выпилить вообще из проекта рендеринг страниц на шаблонах и писать только json-api, а для фронтенда я беру Ember.js
Вот есть, например, такая штука - https://github.com/rails-api/rails-api/ - это то, о чем я говорю, но мне пока страшно брать это, поэтому я делаю все вручную, иногда подглядывая в этот проект.
>> No.35829 Reply
File: OK-nQo3wYvM.jpg
Jpg, 60.57 KB, 630×420 - Click the image to expand
edit Find source with google Find source with iqdb
OK-nQo3wYvM.jpg
>>35776
> Например, у меня есть модели картинки и поста. Картинка привязывается к посту. Хочу создать такую форму, что бы в ней можно было заполнять поля поста, и картинку выгрузить. Но пока умею создавать только одну форму на одну модель. А надо одну на две модели
1) Не использовать form_for, писать свою кастомную форму (да-да, тэгом <form ...>), в контроллере брать значения из params руками, но это не rails-way
2) Использовать form_for, но для кастомной не-activerecord модели (что-нибудь типа PostParams), и из неё уже выгребать значения, которыми ты инициализируешь две свои модели. Немногим лучше первого метода.
3) Вообще не рекомендую хранить пост и картинку в разных моделях. Здравый смысл подсказывает, что модель тебе нужна всего лишь одна - Post, а картинка - это просто поле img_url в посте. Я уже не говорю о соблюдении принципов REST - один контроллер должен работать только с одним ресурсом.
4) Возьми CarrierWave или Paperclip и не парься. Рекомендую CarrierWave.
>> No.35839 Reply
>>35827

Спасибо за развёрнутый ответ.

Только всю часть про Node.js и EventMachine из него надо выжечь калёным железом, потому что ты, видимо, не работал с Node и плохо понимаешь, для чего нужно асинхронное API. Дело в том, что у синхронного API есть одна огромная проблема: оно блокирует поток на время I/O операции. Соответственно, мы получаем либо множество заблокированных потоков, которые отжирают огромное количество ресурсов, либо один поток, который всё время подвисает, снижая общую отзывчивость приложения. В этом смысл асинхронное API - идеальное решение проблемы: оно не ждёт завершения операции, оно, если можно так выразиться, забивает на неё и возвращается к ней потом. В результате несколько потоков-воркеров могут расгрести огромную лавину запросов. Высокая производительность Node - не миф, я сам на ней писал. "На RoR клепать приложения "запрос-ответ" в разы быстрее, чем на ноде" - абсолютно бредовая фраза. Разве что ты имел в виду тенденцию к образованию лапши из callback'ов, но такова цена скорости. В конце концов, есть библиотеки вроде async. Node не течёт и по определению не может - там автоматическое управление памятью. Короче, это нормальная платформа, без особых косяков.

Про масштабирование я всё время вспоминаю историю одного проекта, для которого переписать всё приложение с рельсов на Twisted оказалось дешевле, чем в очередной раз обновлять парк серверов.

Ember.js (а также Angular и иже с ними) я дико недолюбливаю за то, что он без JS не работает. Ладно ещё какие-нибудь игры, их всё равно без него не погоняешь. Но я вот видел на днях новостный сайт на Angular, который не может отрендерить на телефоне свои сраные статичные странички. Кошмар же.
>> No.35840 Reply
File: Zpdk9sB5ZXo.jpg
Jpg, 49.20 KB, 648×484 - Click the image to expand
edit Find source with google Find source with iqdb
Zpdk9sB5ZXo.jpg
>>35839
> не работал с Node и плохо понимаешь, для чего нужно асинхронное API. Дело в том, что у синхронного API есть одна огромная проблема: ....
bla-bla-bla
Да смотрел я кучу презентаций про ноду и писал на ней, что ты мне какие-то пресс-релизные утки рассказываешь? Я прекрасно понимаю, о чем идет речь.
Да, лапша из коллбэков - это серьезный бизнес. Я понимаю твою гордыню по этому поводу :3
Вся эта жаваскриптовая промывка мозгов ни к чему хорошему не привела. Теперь все ньюфаги с пеной у рта доказывают, что синхронный код - это гарантированно плохо и так вообще делать нельзя. Будто бы у вас каждый проект - неебический хайлоад. Я еще раз говорю - в 90% случаев (запрос-ответ) ноду использовать неоправданно. В случае когда нужно просто ответить на запрос и отключиться - нет ничего плохого в синхронной архитектуре рельсов.
Онлайн-игры, чатики - ок, берем ноду, потому что польза асинхронности лучше раскрывается, когда нужно держать одновременно открытыми много соединений. Но у меня не каждый второй проект - веб-сокеты.
> Node не течёт и по определению не может - там автоматическое управление памятью.
Еще один няша, уверовавший во всемогущество сборщика мусора.
А ничего, что ядро ноды на C++?
Те, кто реально работали с нодой на высоких нагрузках, говорят о необходимости перезапускать сервер каждые два дня, потому что нода течет как сука. Сейчас правда утечек всё меньше, потому что ноду активно допиливают, но вот последнее из найденного: http://www.joyent.com/blog/walmart-node-js-memory-leak утечку ловили 3 недели. Текло по 4 байта на каждый закрытый файловый дескриптор. Вот тебе и автоматическое управление памятью.
> "На RoR клепать приложения "запрос-ответ" в разы быстрее, чем на ноде" - абсолютно бредовая фраза.
Да, на RoR объективно быстрее. Язык не такой многословный как JS, есть хорошая ORM. Не надо изобретать лапшу из коллбэков. Разработка в разы быстрее.
А расскажи, как и в чем ты пишешь тесты? Трудно ли тестировать асинхронный код или ты вообще тестов не пишешь? Часто ли всплывают баги с опечатками?
> но такова цена скорости.
Ну я понимаю всё. Коллбэки, героическое преодоление трудностей, серьезный бизнес. Не каждый в такое сможет.
> переписать всё приложение с рельсов на Twisted оказалось дешевле, чем в очередной раз обновлять парк серверов.
Ну если кто-то за еду это переписывал, то конечно дешевле.
>> No.35841 Reply
>>35839
> Ember.js (а также Angular и иже с ними) я дико недолюбливаю за то, что он без JS не работает. Ладно ещё какие-нибудь игры, их всё равно без него не погоняешь. Но я вот видел на днях новостный сайт на Angular, который не может отрендерить на телефоне свои сраные статичные странички. Кошмар же.
О как телефоне и браузере идёт речь? На современных мобильных устройствах всё должно работать нормально. Нет ничего страшного в том, чтобы с каким-то устаревшим гавном ломать совместимость. Да и как без JS в 2013 году?
С другой стороны, я тоже против использования js-фреймворков повсеместно. Когда нужен богатый GUI - без фреймворка никак просто. Но в случае с новостным сайтом и любым другим "сайтом" конечно фреймворки не нужны.
>> No.35844 Reply
>>35840
> В случае когда нужно просто ответить на запрос и отключиться - нет ничего плохого в синхронной архитектуре рельсов.
Есть. Обработка запроса может занять одну-две секунды, и всё это время поток будет заблокированным. Умножаем на число одновременных соединений... ну ты понял.
> А расскажи, как и в чем ты пишешь тесты? Трудно ли тестировать асинхронный код или ты вообще тестов не пишешь? Часто ли всплывают баги с опечатками?
NodeUnit в основном. Не труднее, чем обычный - стиль только непривычен. Нет, багов из-за опечаток в последние месяцы не припоминаю.
> за еду
Ну, я свечку не держал, так что не знаю, какие там были цифры.
> пресс-релизные утки
> героическое преодоление трудностей
Я был бы рад, если бы в ноде появилось асинхронное API, не требующее лапши. Async решает проблему только частично. Хороший пример такого API - vibe на языке D. http://vibed.org/ Оно асинхронное, но выглядит как синхронное. Вот это реально крутая вещь.

А героизм ваш я на хую вертел.
>> No.35845 Reply
>>35844
> Ну, я свечку не держал, так что не знаю
Ну если не знаешь, так чего и болтаешь?
> Умножаем на число одновременных соединений... ну ты понял.
Еще раз: у тебя каждый проект требует c10k или ты просто максималист?
Подозреваю, ты и ноду-то на нагрузках не гонял, потому что уже показал свою некомпетентность, ничего не зная об утечках.
> А героизм ваш я на хую вертел.
А я на хую вертел Node.js, EventMachine и Twisted, потому что это всё детские игрушки по сравнению с Erlang. Там, где не справляются рельсы, я беру Erlang. Все эти проблемы с количеством соединений в эрланге уже давным-давно решены. В эрланге свой планировщик, lightweight processes, которых можно насоздавать сотни тысяч. Ты конечно скажешь, что у тебя в ивент-лупе тоже может быть сотни тысяч ивентов, но процессы в эрланге - штука более умная, чем твои обоссаные ивенты. Они линкуются в supervision-деревья, можно задавать рестарт-стратегии. Всё это намного лучше масштабируется по CPU буквально из коробки, а в твоей сраной ноде только дебильный 'cluster' с round-robin. Следуя правильным паттернам, я получаю надежную пуленепробиваемую систему на Erlang, а ты продолжай жрать свои калбачные макароны.
>> No.35846 Reply
>>35845
> показал свою некомпетентность, ничего не зная об утечках
Отличная фраза, бро. После такой хочется лечь и умереть. Но я всё-таки поясню ситуацию: я полагал, что ты говоришь об утечках памяти в JavaScript, на что я тебе ответил вполне резонным замечанием о том, что в языке с автоматическим управлением памяти их быть не может. Это верно при условии, что в самой VM и нативных библиотеках утечек тоже нет. Окей, они там тоже могут быть. Я вот никогда не замечал за Node перерасхода памяти, но ладно, от ошибок никто не застрахован.
> детские игрушки по сравнению с Erlang [стена текста]
Стена текста написана зря: я знаком с Erlang. Про него я могу сказать хорошего только одно: стабильно высокая производительность. Erlang рвёт Node, базару ноль. Нода хороша до того момента, пока GC справляется. Как только этот предел превышен, она начинает дёргаться и заикаться. В этом смысле Erlang больше похож на танк.

Вот только программы, написанные на нём, совершенно невозможно поддерживать. Даже не потому, что он функциональный, хотя и поэтому тоже. Ruby - ещё куда ни шло. Erlang - не-е-е-е. Нужно быть совершенно упитым, чтобы добровольно согласиться поддерживать приложение на нём. В этом смысле Node.js - самый лучший компромисс между производительностью и лёгкостью поддержки.

(Смешно осознавать, что такой срач "Erlang vs. Node" поднялся после того, как я про Rails спросил.)
>> No.35847 Reply
>>35846
Erlang не чисто функциональный, при детальном рассмотрении это всё тот же скриптовый язык. Там нет ломающей мозг ленивости, не нужно "заворачивать сайд-эффекты в монады" как в Haskell. Он примитивен как lisp, но читать эрланговый код намного легче. Я утверждаю, что Erlang нормально можно выучить за месяц - после месяца практики уже совершенно точно перестанешь спотыкаться, сможешь нормально писать и читать чужие исходники. Я не понимаю, в чем проблема.
> совершенно невозможно поддерживать.
Просто мало кадров, которые смогли бы поддерживать. С этой точки зрения я бы на месте менеджеров плотно призадумался, целесообразно ли начинать проект на Erlang. С другой стороны в России есть команды, которые целиком пишут на Erlang - в целом довольно положительный опыт.
Сейчас любят говорить "выбираем node.js, потому что javascript знают все" - очень спорный аргумент, я считаю. Мало кто по-настоящему врубается даже в JS, там тоже нужно многому научиться. Так почему бы сразу не учить Erlang?
>> No.35848 Reply
>>35841
Мимопроходил, но бред. Восторженные возгласы хаброблядей. Новые технологии, 2013! Кококо! Статик не нужен! У всех есть! Правда жизни же такова, что для некоторых проектов приходится поддерживать отключенный js и лезть в about:config, чтоб протестировать работу страницы с выключенным js, потому что мозилла тоже решила, что кококонинужно. В смысле, не "хорошо бы", не "должно работать, ибо так правильно", а есть реальный проект где для нескольких страниц работа без js является необходимостью, ибо продажи. Js на них тоже есть, но и без него они должны работать (отличается поведение, само собой). Потому что если пользователь не может открыть твиттер на своей микроволновке — это проблема пользователя. А вот если он не может заполнить присланную платёжную форму с заказом на приличную сумму, то это уже твои проблемы.
>> No.35849 Reply
Еще меня раздражают всякие вспомогательные штуки, которые зачем-то пишут на Node.js
npm, bower, grunt, yeoman - тысячи их.
Когда я смотрел исходники bower, я дико путался в его колбаковой лапше. Спрашивается, зачем такие проекты пишут на node.js? Скрипты вполне естественно писать в синхронном стиле, зачем им асинхронный ввод/вывод ? Ну конечно приятно, когда они скачивание зависимостей запускают параллельно, но это можно сделать и по-другому.
Вот тот же bower сам признал, что код превратился в неподдерживаемую лапшу: "Bower code base is becoming unmanageable" - https://github.com/bower/bower/wiki/Rewrite-architecture
В общем, пугает меня вся эта мода на JavaScript. Убогий язык, синтаксически шумный, много подводных камней, на которые натыкаешься из раза в раз. И вся трагедия в том, что от него уже поздно отказываться - зафорсили по самое не балуйся. Надо было давно выкинуть JS из браузеров пока не стало поздно. Надо было изначально сделать в браузерах нормальную VM, под которую можно было бы компилироваться каким угодно языком, и не пришлось бы корячиться и изобретать v8. Я не хочу компилировать CoffeeScript в JavaScript - идею транслировать один высокоуровневый язык в другой считаю самым настоящим костылем. Просто другого выхода нет и приходится писать на более няшном и безопасном CoffeeScript, чтобы сэкономить время и нервы. Такие дела.
>> No.35850 Reply
>>35849
JS довольно хороший язык, ты просто в него не умеешь, вот тебе всё и плохо. Вспомогательные штуки пишут, как ты сам верно заметил, именно потому, что модно. Плюс, npm — лучший пакетный менеджер на сегодня. Да и потом, все языки — говно, поэтому всегда "лучше было бы на чём-то другом", вот только на чём? На пайтоне? Да по правде что так плохо, что сяк. Руби? Как язык он спроектирован прилично, но если хочется фапать на язык — фапайте на лисп. На практике же это какое-то дикое перлоподобное говно, где можно одно и то же написать сотней способов, манкипатчить, да оно ещё и медленней всех в своей весовой категории. По сути, природа его популярности ровно такая же, как природа популярности ноды. Собственно, всякие там bower-ы и написаны бывшими рубихипсторами из твитора, которые поняли, что дальше так жить нельзя и переписали всё на скалу (которая тоже пиздец ещё тот, конечно, но это только начинают признавать, поскольку она только-только, собственно, становится популярной).
> писать на более няшном и безопасном CoffeeScript
Ещё один ушибленный. Вместо того, чтоб один раз выучить нормально js и пользоваться им он транслирует сладкий хлеб в… Ну тоже вещь неидеальную, которую, ко всему прочему, так и так приходится знать, чтоб писать на этом вашем кофе. Да ещё и с каким-то убогим рубиподобным синтаксисом. Нет, ну я тоже в него поиграл одно время пока это не стало популярным, да, но со временем выяснил, что профит в общем-то нулевой, ибо js и так гибок как резина, бойлерплейта выходит не так уж и много, а в скорость нажимания на клавиши программирование всё равно не упирается. Если уж и использовать препроцессор, то какой-нибудь там кложурскрипт, но дебажить говно, выдаваемое транслятором (да-да, даже с source-maps) получается затратней, чем просто писать сразу на многострадальном js. "На js писать сложно, это мазохизм, блаблабла". Вот почему мне не сложно?

В общем, вывод который я для себя сделал: все ЯП, и даже всё ПО — говно, и от этого не спастись. Сорта говна делятся на две большие категории — те, которые используют потому что можно, и те, которые используют, потому что нужно. Очевидно, что мало говна — лучше, чем много говна, поэтому говно из первой категории лучше не трогать. Помимо этого, желательно по возможности переносить говно из второй категории в первую, чтоб в последствии забыть о нём вовсе. Так вот, что руби с рельсами, что нода находятся в первой. Их использование может быть оправдано, но случается это редко, и, по сути, все ЯП этой весовой категории (js, ruby, perl, python, php) мало чем существенно различаются. Препроцессоры над этими языками и вовсе учитывать не стоит, они по определению в первой категории. Теперь: js выкинуть нельзя, ибо он в своей области незаменим. Его придётся знать, поэтому нужно стерпеть боль и придти к состоянию, когда писать на нём можно будет легко и непринуждённо. Как уже было замечено тобой и подтверждено мной, нода не решает столько проблем, сколько создаёт, значит для написания лёгеньких бэкендов нужно выбрать что-то ещё. Ок, давайте исходить из того, что всё названное — говно, что же нельзя не-использовать? Поразмыслив, придём к выводу, что python заменяет больше ЯП, чем любой из названных (только им, скажем, можно заменить R и Matlab, и вообще для любых сложных, т.е., наукоёмких, программ, которые мы можем захотеть использовать в продакшене не переписывая их на блядские кресты или джаву, он — единственный возможный вариант).
> Надо было изначально сделать в браузерах нормальную VM
Так что ж ты не сделал, раз ты такой умный? Я сам отвечу: ты, как и я, ходил тогда в школу, а не работал в нетскейпе. Так что теперь перестань выёбываться и не охай о том, как "нужно было бы", а face the music и используй то, что есть. Родина дала ему джаваскрипт — пользуйся. Нет, не хочу пользоваться, хочу кофискрипт жрать…
>> No.35851 Reply
>>35848
> для некоторых проектов
Сам же говоришь.
>> No.35852 Reply
>>35848
> протестировать работу страницы с выключенным js, потому что мозилла тоже решила, что кококонинужно
Почему именно мозила? Только лисобоги что ли жс отключают повсюду?
>> No.35857 Reply
File: talking_captcha.png
Png, 0.61 KB, 300×20
edit Find source with google Find source with iqdb
talking_captcha.png
File: normal_Kkcil_05.jpg
Jpg, 79.34 KB, 636×803
edit Find source with google Find source with iqdb
normal_Kkcil_05.jpg

>>35849
> Я не хочу компилировать CoffeeScript в JavaScript
Ещё есть TypeScript http://www.typescriptlang.org/ но похоже, что он бесполезен без Visual Studio.

А будущее всё равно за Derby.js, Meteor.js и аналогичными.
One JS to rule them all, one JS to find them,
One JS to bring them all and in the darkness bind them.
>> No.35866 Reply
>>35847
> Erlang не чисто функциональный
Чистота языка - отдельный вопрос. Мне на самом деле наплевать, чист он или нет: он всё равно выглядит и работает как функциональный язык.
> ломающей мозг ленивости
Если ленивые вычисления ломают тебе мозг, то проблема в мозге. В С++ у тебя тоже выражения вида "if (someConditionMet() || someOtherConditionMet())" вызывают неприязнь из-за того, что правая часть выражения необязательно будет выполнена?
> примитивен как lisp
Некорректно сравнивать функциональный язык с мультипарадигменным.
> читать эрланговый код намного легче
В 15% случаев - да, в 85% - решительно наоборот.
> после месяца практики уже совершенно точно перестанешь спотыкаться
У меня практики гораздо больше, чем месяц, и всё равно некоторые вещи дико заёбывают.
> в России есть команды, которые целиком пишут на Erlang - в целом довольно положительный опыт
Исключения случаются.
> javascript знают все
Мне наплевать, сколько людей его знает - важно то, что язык сам по себе понятен и не провоцирует глупые ошибки.


>>35849
> раздражают npm, bower, grunt
Не заглядывал в их исходники, но внешне это прекрасные утилиты. Особенно Grunt.
> CoffeeScript
Отличный язык, к слову.


>>35857
> Meteor.js
Реально крутая штука. Но не слишком удобная.

Вообще, на мой взгляд, у фреймворков, навязывающих проекту свою структуру, нет будущего. Только я знаю, как мне лучше организовать своё приложение, и мне нужны не рамки, а инструменты. И Sinatra в этом смысле куда лучший вариант, чем Rails.
>> No.35871 Reply
>>35850
> JS довольно хороший язык,
> скалу (которая тоже пиздец ещё тот
> рассуждения про то что динамические языки говно
Что-то я не пойму, ты динамический питушок, или дохуя хаскелист?
>> No.35872 Reply
>>35866
> Чистота языка - отдельный вопрос. Мне на самом деле наплевать, чист он или нет: он всё равно выглядит и работает как функциональный язык.
> Некорректно сравнивать функциональный язык с мультипарадигменным.
Ответь на вопрос пожалуйста: почему ты называешь Erlang функциональным? Какими чертами ФЯП он обладает?
Почему Erlang у тебя по большей части функциональный, а LISP всё-таки мультипарадигменный?
> Если ленивые вычисления ломают тебе мозг, то проблема в мозге. В С++ у тебя тоже выражения вида "if (someConditionMet() || someOtherConditionMet())" вызывают неприязнь из-за того, что правая часть выражения необязательно будет выполнена?
Оператор || - это всё, что ты знаешь о ленивости? Я имел в виду в общем смысле стратегию вычислений call by need, порой далеко не всё так тривиально, как в твоем примере.
>> No.35885 Reply
>>35872
> Почему Erlang у тебя по большей части функциональный, а LISP всё-таки мультипарадигменный?
Ну хотя бы потому, что в Erlang есть pattern matching.
> порой далеко не всё так тривиально, как в твоем примере.
Кто бы спорил. Вот, например, функция, вычисляющая сумму двух чисел:
int sum (int x, int y)
{
    return x+y;
}
Порой функции далеко не так тривиальны, как в моём примере. Ну и что? Примера с || достаточно, чтобы продемонстировать суть: это некий набор команд, относительно которого не даётся гарантий того, что он вообще когда-нибудь выполнится, а если выполнится, то когда. Усложняет ли это понимание программы? Конечно - ведь для каждого куска кода появляются лишние зависимости. Растёт ли от этого производительность? Ещё как. Так что это вполне нормальный способ оптимизации. Ты, может, хотел сказать, что в нём не всегда есть необходимость? Ну так я согласен. Я утверждаю лишь то, что в большинстве случаев выигрыш в производительности оправдывает мучения. Это относится к любому языку; ну а Haskell сам по себе не особенно быстрый, так что ему есть смысл эту оптимизацию применять.
>> No.35887 Reply
>>35885
> это некий набор команд, относительно которого не даётся гарантий того, что он вообще когда-нибудь выполнится, а если выполнится, то когда
Ты по всей видимости понимаешь ленивость слишком локально. Основная фишка всё-таки не в том, что "выражение может никогда не вычислиться", а в мемоизации уже вычисленных выражений и в том, что используется графовая редукция выражений. И в этом кстати вся суть, что редукция происходит именно на произвольных графах, а не на деревьях, как в случае со strict evaluation, и это как раз всё меняет. Также есть бесконечные списки - тоже скажешь "оптимизация"? Нет, это уже фича, которая становится возможной только при наличии lazy evaluation. Всё это имеет очень мало общего с твоим примером из крестов. Твой пример из крестов - это даже больше не оптимизация, а попытка облегчить жизнь крестьянам, дав им семантику монады Maybe прямо в языке. А оптимизациями все-таки называется кое-что другое.
> Усложняет ли это понимание программы? Конечно
Ну так чего ж ты тогда обзываешься на мой мозг, если сам говоришь, что ленивость объективно затрудняет читаемость?
Возвращаясь к Erlang, напомню что ленивости там нет, а стало быть и читать его намного проще. Отсутствие ленивости кстати многое меняет. Без ленивости, без чистых функций и изоляции сайд-эффектов "функциональный язык" перестает быть таким уж функциональным и встает в один ряд с лиспом, ruby и прочим. В Erlang ничего этого нет. Вот выкинь мутабельность из JS или Ruby - получишь что-то лиспо-подобное. Erlang - не более чем скриптовый язык без мутабельности, и как следствие тебе просто навязывают "функциональный стиль", а это уже не так опасно для мозга, как pure functional programming. Наличие упомянутого тобой паттерн-матчинга кстати ни о чем не говорит - само по себе это еще не функциональщина. Erlang - это не более чем lisp, но с хорошим concurrency на акторах ну и с этим твоим паттерн-матчингом.
>> No.35901 Reply
>>35887
> Ты по всей видимости понимаешь ленивость слишком локально [стена текста с другими примерами]
Да нет, мне как раз известно всё это. Если я не написал про мемоизацию - это не значит, что я про неё не знаю; это значит только то, что я про неё не написал. Мы с тобой обсуждали не фичи такого подхода, а его недостатки, и именно отложенное исполнение порождает большинство из них. Ещё раз: тот пример из мира С++ представляет собой простейший пример ленивого вычисления, и он прекрасно вписывается в общую концепцию. Из неё же вытекает и тот факт, что ленивые вычисления - вещь вполне терпимая, и если человек считает её мозговыносящей, то у него серьёзные проблемы с абстрактным мышлением.
> Ну так чего ж ты тогда обзываешься на мой мозг, если сам говоришь, что ленивость объективно затрудняет читаемость?
Да потому что не настолько она затрудняет, чтобы на неё ругаться. Макросы препроцессора тоже затрудняют читаемость, но это не повод отказываться их использовать.
> Наличие упомянутого тобой паттерн-матчинга кстати ни о чем не говорит
Дожили.
> мутабельность
В программировании нет такого понятия. Что ты имел в виду? First-class functions?
> Erlang - это не более чем lisp
Erlang - это не лисп хотя бы потому, что у него есть синтаксис. А ещё у них разная идеология и разные задачи.

(Лирическое отступление: у лиспа, если кто не знает, нет синтаксиса языка как такового, а код программы представляет собой синтаксис записи AST - абстрактного синтаксического дерева. В других языках первая задача компилятора - преобразовать синтаксис языка в AST, из которого потом будет генерироваться машинный код. В лиспе этого этапа нет: код программы и представляет собой уже готовое AST. Благодаря этому лисп помимо всего прочего ещё и мощный метаязык, потому что он может собирать внутри себя AST с другими программами и отдавать их на исполнение; кроме него на такие штуки способен разве что ассемблер.)
> Без ленивости, без чистых функций и изоляции сайд-эффектов
Ленивые вычисление - не признак функционального языка; как я уже говорил, это всего лишь способ оптимизации.

А всё остальное Erlang имеет. В нём чистые функции без побочных эффектов. (Несогласные могут попытаться передать список в функцию так, чтобы исходный список изменился, или просто изменить значение переменной.) Не изолированы в нём только I/O операции и ещё пара вещей. С точки зрения чистоты языка это непростительно, но лишь благодаря этому отличию на Erlang сейчас пишут хайлоад-системы - в отличие от хаскеля, которым пользуются три с половиной профессора математики.
> опасно для мозга
Опасных для мозга вещей в программировании вообще не существует. Все проблемы - в мозге. На всякий случай повторю, что не всякий язык подходит для всякой задачи, и соображения удобства/практичности/лёгкости поддержки никто не отменял. Но таких вещей, которые могли бы рвать мозг, нет. Это лишь вопрос способности воспринимать концепции.
>> No.35902 Reply
В каком-то тьюториале по РоР было написано, что РоР - для сложных веб-приложений. Если вам достаточно вордпресса, то не нужно хвататься за РоР. А есть CMS на руби такие же годные как Drupal, Jumla и Wordpress?
>> No.35903 Reply
>>35902

Octopress.
>> No.35904 Reply
>>35903
Годный, но он же только статику генерирует по шаблонам?
>> No.35968 Reply
Анон, я ищу работу и у меня нет опыта. Если я сделаю какой-нибудь сайт, не очень простой, то стоит ссылку на него в резюме вставить? Или это только насмешит, когда всего один сайт?
>> No.35970 Reply
>>35968
А мне вот интересно, как работодатели относятся к тому, что ты написал имиджборду.
>> No.35972 Reply
>>35970
На хаскеле?
>> No.35975 Reply
>>35972
На RoR.
Ну да, тут такой очень тонкий момент. "Написал имиджборду на хаскеле" - это с т.з. работодателя уже диагноз.
>> No.35976 Reply
>> No.35982 Reply
File: 1386539445125.png
Png, 0.85 KB, 300×20 - Click the image to expand
edit Find source with google Find source with iqdb
1386539445125.png
И снова про имиджборды.
Номер каждого треда/поста дожен быть уникален, как я понимаю.
Как это лучше всего организовать? Хранить где-нибудь номер последнего поста? Где и как? Не будет ли проблем, когда 2 пользователя попытаются создать треды практически одновременно?
Лучше ли заводить отдельные модельки для постов и тредов? А то уж больно много у них общего.
Если использовать и там, и там, одну и ту же модель, то как понять, что есть ОП-пост, а что есть обычный пост? Как понять, какой пост какому треду принадлежит? И не получается ли при таком подходе всё слишком сложным?
Или сделать абстракную модель (как бы её назвать?) и от неё наследовать пост и тред?

Rails 4.0.2, если что.
>> No.35989 Reply
>>35982
О боже, "номер поста" - это всего лишь id записи в БД, который автоинкрементируется.
> Не будет ли проблем, когда 2 пользователя попытаются создать треды
Что-нибудь про принцип ACID слышал? Марш читать про базы данных!
> Лучше ли заводить отдельные модельки для постов и тредов? А то уж больно много у них общего.
В вакабах всяких так не сделано и это во многом правильно. С другой стороны, решать тебе. Если всё-таки решишь делать их отдельными, то постарайся не зафейлить целостность и при создании треда сначала создаёшь пост, а потом тред.
>> No.35999 Reply
>>35982
THIS IS SQL СУБД TIME!
>> No.36000 Reply
>>35982
Алсо, а как это ты атк учил рельсы, не сталкиваясь с СУБД и моделями?
>> No.36001 Reply
>>35989
> О боже, "номер поста" - это всего лишь id записи в БД, который автоинкрементируется.
Вот оно может и автоинкриментируется, но если отдельные модели для поста и треда, то могут быть совпадения. Об этом-то я и писал.
> Что-нибудь про принцип ACID слышал? Марш читать про базы данных!
Okay. Хотя я всегда считал, что ACID - это тест на совместимость браузера с веб-стандартами. Мой firefox 25 проходит ACID 3 на 100%.
> В вакабах всяких так не сделано и это во многом правильно.
Хорошо, посмотрю на всякие вакабы.
>>36000
Не учил, а учу. Про модели пока только общие понятия знаю. Буквально вчера гуглил про абстрактные модели в Rails. И before_save-callback не сразу завёл, например.
>> No.36006 Reply
>>36001
Асид не торт, его нынче даже ие проходит.
>> No.36008 Reply
>>36001
Тебе нужна книжка или что-то по СУБД. Хотя бы почитать о ER-моделях и отношениях 1:n и n:m(один ко многим и многие ко многим) и их реализацию таблицами с использованием внешних ключей(foreign key). Внешний ключ - это айдишник другой таблицы. Например, посты будут хранить айдишник треда, к которому они прикреплены. При этом они могут упорядочиваться, скажем, по дате создания, так что самый первый будет ОП-постом.
>> No.36009 Reply
>>36008
Плюс, про параллелизм в СУБД тоже что-нибудь. Один словом, в СУБД есть готовые механизмы автоматического разрешения проблем параллелизма, но дополнительная настройка этих механизмов может улучшить производительность.
>> No.36010 Reply
>>36001
Короче, не храни тред в отдельной модели. Что ты в ней вообще хранить собрался?
>> No.36011 Reply
Когда пишешь имиджборду, треды-как-модели лучше использовать только если у тебя например mongodb. И тогда можно хранить одни только треды, а посты - это вложенный массив в объект треда. Никакого ебучего 1:N, к тому же тред всегда целиком запрашивается, и тут прирост производительности очевиден. Надо только с превью треда на главной разобраться - как показывать последние X постов.
>> No.36012 Reply
File: vonnimask-147477.jpeg
Jpeg, 39.47 KB, 490×426 - Click the image to expand
edit Find source with google Find source with iqdb
vonnimask-147477.jpeg
>>36001
> модели для поста и треда, то могут быть совпадения
Так обычно не делают для имиджборд.
Я наверно сделал бы так:
Post
  id
  parent_id # если null/nil то значит ОП
  text
  images    # тут можно просто айди картинок склеить через запятую
            # а можно и отдельную PostImages завести
>> No.36013 Reply
>>36010
>>36011
>>36012
Вы меня в конец запутали окончательно? Так какие вы предлагаете модели/модель использовать для постов и тредов? И с какими столбцами?
> # тут можно просто айди картинок склеить через запятую
Это не нарушит нормализацию?
>> No.36014 Reply
>>36013
Нарушит, но типа производительность и всё такое. Делай как знаешь, в общем.
>> No.36015 Reply
>>36014
То есть бывают случаи, когда производительность теряется от потворствования нормализации? Видимо, мне надо въехать в БД получше. А поиск постов по таблице, по такой схеме из >>36012 будет типа быстрее чем найти все посты треда по внешнему ключу? Чому 1:n - ебучее? Индексами нельзя сделать быстрый поиск всех постов с одним thread_id?
>> No.36017 Reply
>>36015
Ессно бывают, придётся отправлять ещё один запрос. Но лучше всё-таки доп. таблица из двух колонок "postid, imageid" хуже не будет.

Поиск и навигатор - в любом случае через отдельные таблицы.

Индексами делается выбор нужных постов (но не поиск).
>> No.36018 Reply
>>36017
В чём различие между выбором и поиском?
>> No.36019 Reply
>>36018
Я бы сказал, что при поиске делается объединение нескольких таблиц (word, word-post, post), а выбор - это просто выбор по ключу в таблице, и всё.
>> No.36020 Reply
>>36019
> word, word-post
Таблицы слов и их вхождений? Серьёзно?
>> No.36021 Reply
>>36020
Если не бросать в первую таблицу короткие слова и цифры, а также ограничить длину запроса (не более 10 слов), то будет работать.

Может быть, full text search быстрее работает, я не проверял. Так и тащил за собой старые исходники, потом выбросил.
>> No.36022 Reply
>>36012
Вот мне твой вариант больше всего нравится. А как это будет Post hasmany Post и Post belongsto Post?
Олсо, почитал тут, похоже, не я один пишу имиджборду на рельсах.
>> No.36023 Reply
File: nicolas-cage-will-be-in-the-expendables-3.jpg
Jpg, 23.47 KB, 714×536 - Click the image to expand
edit Find source with google Find source with iqdb
nicolas-cage-will-be-in-the-expendables-3.jpg
>>36022
> Олсо, почитал тут, похоже, не я один пишу имиджборду на рельсах.
>> No.36024 Reply
>>36023
Не я один в этом треде, имелось в виду.
>> No.36025 Reply
>>36024
А кто ещё?
>> No.36026 Reply
>>36025
>>36013-анон - это не >>35982-анон, потому что последний - это я.
>> No.36027 Reply
>>36026
Это вообще я. Я заинтересовался, потому что другой анон нарушил мои представления о работе с данными.
>> No.36028 Reply
>>36027
Да, но тебя приняли за меня.
Так ты просто заинтересовался или реально пишешь имиджборду на RoR?
>> No.36029 Reply
>>36028
Не пишу я никакую имиджборду.
>> No.36058 Reply
Стал делать так, как советовал >>36012-анон.
В общем, в app/views/posts/show.html.erb делаю render 'form', что бы создать новый пост в треде.
Но форма отрисовывается для обновления оп-поста текущего треда. Можно ли явно задать экшн, в render, или надо полностью рисовать форму ручками через form_for?
>> No.36059 Reply
Аноны, в чём смысл spork и guard? Их надо перезапускать после каждого изменения файлов, что ли? Если да, то в чём их смысл? Или когда их перезапускать?
>> No.36088 Reply
>>36059
Один раз в начале сессии хакинга запускаешь, и они следят за директорией проекта, следуя указаниям из файлов конфига: создают тестовые инстансы и запускают тесты, как файлы изменятся - все сами. Откуда такие идеи про перезапуски?
>> No.36089 Reply
>>36088
Я протупил. У меня нотификейшны вылезали по 3 штуки и не исчезали очень долго, а я не мог понять, почему оно не реагирует на изменения. Убунту десу. "Файлы~" как-то конфликтовали, добавил их в ignore в гардфайле. И сами нотификейшны в убунту не убыстряются без конфигурации каким-то левым неоффициальным патчем. Супер-продвинутый юзер-френдли дистр не может в указание времени нотификейшна через либнотифай.
>> No.36093 Reply
>>36089
Да, помню, тоже долго с этим ебался. В конце концов отрубил бэкапы (заигнорить не догадался), а оповещения слил в емакс, там с ними оказалось проще.
>> No.36284 Reply
itshouldbehave_like в rspec/capybara применяется к subjet как it. Как применить тоже разделённый пример, но используя expect(что-то).to? Нужно, чтобы проверять работоспособность ссылок, кликая на них, потому, что при кликах страница меняется и it не работает.
>> No.36285 Reply
Пристрелите меня. Guard на одном проекте прекрасно работает, а на втором так же настроил и он улавливает исключительно изменения спеков, но не каких-либо связанных файлов. Гардфайлы идентичные, взятиые с тьюториала Майкла Хартла по рельсам. Это может быть как-то связано с созданием вложенных лейаутов или переписыванием реквайров таблиц стилей в манифестах? Или с тем, что у проекта и контроллера одинаковые имена?

Как его вообще заставить работать?
>> No.36286 Reply
>>36285
Разобрался. Оказывается, Харл подразумевал, что контроллеры называются со словом _pages на конце. Это конвенция какая-то?
>> No.36296 Reply
В php сообщения отправляются сами собой после установки каких-то там программ. А почему в рельсах мне предлагают вводить какие-то логин-пароли от почтового аккаунта для отправки сообщений с сайта. Чем объясняется эта разница? И кто из php и rails прав в этом, то есть что лучше?
>> No.36316 Reply
>>36296

Ну, судя по всему, рельсы отправляют сообщения через почтовый сервер, а РНР сам действует в качестве такового. Какой вариант лучше - трудно сказать. От своего имени отправлять, конечно, удобнее, но твоему серверу никто не обязан доверять - например, Яндекс все сообщения подписывает цифровой подписью, а тебе это сделать проблематично; Яндекс никогда не внесут в чёрные списки, а тебя могут.
>> No.36320 Reply
Блин, почему всё время разбора рельс и руби уходит на rspec, capybara и прочее к ним относящееся. За пару минут написал функциональность и часами туплю, почему тест не работает. Хартл учит использовать guard, чтобы тесты автоматически запускались. Очень круто, они быстро запускаются и фоном дают нотификейшны. Но тут я просто пытаюсь в тесте кликать на картинку. На тег img, а не на тег a, который его содержит. racktest, веб-драйвер по умолчанию используемый капибарой не хочет протягивать клик в родительские элементы и клик по img не работает. На стек оверфлоу написано, что racktest тупит и возьмите лучше selenium. Запустил с селениумом. Тесты конечно проходят, но нафига он открыл фаерфокс и мельтешит им перед носом, да ещё работает медленнее в 20 раз буквально. И это для протягивания кликов и джаваскрипта? А нет быстрого и умного веб-драйвера? Или хотябы умного, но headless, без мельтешения. Как настоящие rails-ниндзи тестируют? Я точно делаю что-то не так.
>> No.36321 Reply
>>36320
Нижние подчёркивания поплыли, туды их.
>> No.36323 Reply
>>36320
Сейчас проверил, мои тесты запускаются без спорка на rack-test - 9 секунд, а на selenium - 2 минуты. Это ужас.
>> No.36334 Reply
>>36323
Нашёл в принципе решение. Capybara-webkit даёт 40 секунд на этих тестах и никаких браузеров не запускает и умнее чем rack-test. Можно использовать применительно к отдельным тестам.
>> No.36429 Reply
>>36316
> > Ну, судя по всему, рельсы отправляют сообщения через почтовый сервер, а РНР сам действует в качестве такового.
Что я читаю. PHP не работает в качестве почтового сервера, если ты про комманду mail так это почтовик установленный в системе. Подозреваю что в рельсах можно сделать также. Ну и в любом случае ты указываешь кому адресуешь письмо и от кого.

Кста я видел код на PHP который открывал сокеты и формировал письмо без почтовика и это было можно даже сказать изящно.

чтобы не быть голословным
http://php.net/manual/ru/function.mail.php
http://www.tutorialspoint.com/ruby/ruby_sending_email.htm

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

>>36296
> > И кто из php и rails прав в этом, то есть что лучше?
зависит от задачи, есть высокая нагрузка на отправку почты, (более ста соощений в секунду) изучай как отправить сообщение минуя почтовик или возможно раскидать сообщения по разным почтовикам, нет нагрузки встроенный в систему почтовик сойдет. А вообще не ленись протестируй эти моменты, ты должен знать когда система откажет.
>> No.36432 Reply
>>36429
> http://www.tutorialspoint.com/ruby/ruby_sending_email.htm
Зачем это нужно, в Rails же есть ActionMailer с шаблонами.
>> No.36440 Reply
>>36432
Не против кинуть ссыль на ActionMailer с шаблонами?
Никогда не писал на руби.
Вобще было бы весьма не плохо если гуру руби накидают манов и туториалов как в треде с питоном.
>> No.36491 Reply
Никак не могу заставить ссылки#срешётками работать с turbolinks в хроме. В опере и фаерфоксе - всё ок. Без турболинкса - тоже. Блин, очень не хочется от чего-то отказываться. Что делать?
>> No.36492 Reply
>>36491
Обновить джем догадался, а rails server перезапустить - нет. Когда я поумнею?
>> No.36493 Reply
>>36492
Работало в опере, не работало в хроме. После обновления джема - наоборот!
>> No.36494 Reply
>>36493
Оу, оперу перестали обновлять под линух? Блин, из виртуалки теперь и её, что ли запускать...
>> No.36574 Reply
Тут кто-нибудь читал этот ruby on rails tutorial Хартла? Он меня совсем запутал. Чтобы реализовать вход/выход юзеров он не использует как таковые сессии, а использует кукисы и хранит в них сгенерированные токены, а БД - их дайджесты. Почему для аутентификации нельзя было просто хранить айдишники юзеров в сессиях? Такое ощущение, что он изобрёл сессии. Может, я что-то не понимаю? Просто хранить айдишники юзеров в сессиях не так безопасно?
>> No.36575 Reply
>>36574
Я бы тоже так делал.
Всегда можно было бы отправить в БД запрос на чистку сессий.
А с файловой системой чистить каталог с текстовыми файлами - долго и медленно.
>> No.36576 Reply
>>36575
Доброчую этого. Никогда, никогда не храните сессии в текстовых файлах если сайт имеет хоть минимальный шанс стать популярным. Потом это становится большим-большим геморроем.
>> No.36577 Reply
>>36576
>>36575
Чёрт, вы меня запутали. По видимому я что-то протупил при изучении HTTP. Я думал сессии сохраняются простым обращением к хешу session и работа этого хеша должна из коробки прекрасно работать. Проблема только в том, что эти изкоробочные сессии будут храниться в файлах? А как-то их в базу перенаправить нельзя?
>> No.38213 Reply
>>35662
>>35608
какие-то невеодыме доселе велосипеды.
примерно так должно быть:

resources :boards, only[:show, :index] do
   resources :topics
end

ну и про to_param почитай
>> No.38267 Reply
Господа, подскажите как быть. Меня сильно заинтересовал руби и рельсы, есть неплохие навыки фронтенда, но я использовал сраные CMS, пропустил MVC и теперь адски трудно его понять этот принцип. Можете объяснить MVC в рельсах в виде детской сказки ну или на худой конец кинуть линк на маны? Вроде и книжки читал и скринкасты смотрел, но огромное количество соглашений не уклыдвается в голове, не дает общей картины.
>> No.38268 Reply
>>38267
> но я использовал сраные CMS, пропустил MVC
Ты вёрстку хоть натягивал? Типы контента создавал. Как ты их использовал? С ООП знаком? Навыки фронтенда у него неплохие.
>> No.38269 Reply
>>38268
Натягивал и на рельсы в том числе, разбивал на парциалы и всё такое. По поводу CMS - в основном я использовал Modx, поэтому MVC и прочие прелести остались для меня не познанными. ООП в рамках codecademy, codeschool, быдлокодил на js калькуляторы, xPDO в контексте MODX опять таки представляет БД в виде объектов.
>> No.38272 Reply
>>38269
Файлы с вёрсткой, шаблоны - представление. Модель - это класс объектов в виде которых представляется БД. Контроллер - это класс, методы которого получают инфу из запроса, общаются с БД через эти объекты и подбирают шаблон, подготавливая к нему данные. Какой запрос, в какой метод какого контроллера идёт настроено в routes. Кроме того есть REST - конвенция по созданию контроллера и шаблонов для конкретной модели. Почитай у Хартла.
>> No.38719 Reply
>>38272
Нашел себе идеальное введение в рельсы - видеокурс на teamtreehouse.com
>> No.39357 Reply
File: dennis-ritchi_2.jpg
Jpg, 27.55 KB, 550×367 - Click the image to expand
edit Find source with google Find source with iqdb
dennis-ritchi_2.jpg
Я пытаюсь обмазаться страным форумом на рельсах. https://github.com/discourse/discourse
Он при развёртывании локально предписывает запускать Vagrant. Читаю в гайды у них на гитхабе и вообще никак не въезжаю, зачем для веб-приложения на рельсах может использоваться какая-то виртуальная машина. Объясните нубу.
>> No.39358 Reply
>>39357
Это что-то вроде денвера для похапе, судя по всему. Чтобы сразу всё нужное окружение поднять.
мимо
>> No.39384 Reply
Блин, они меня совсем запутали. Почему при запуске assets:precompile могут быть какие-то там проблемы с аутентификацией в базе? Да ещё с именем пользователя, которого я точно нигде не вводил.
>> No.39526 Reply
как создать гем?
>> No.41430 Reply
а что если я не хочу платить кодскулу и буду просто смотреть их платные скринкасты повторяя что делают - нормально? или там какие-то рандомные задания.
И куда переходить после всего Path ror?
>> No.41536 Reply
Рубяши, а как вы смотрите какие есть методы у объекта. .methods возвращает жуткую кашу же, можно как-нибудь возвращать, к примеру, только собственные методы или собственные методы + методы наследников до N колена?

И еще не смотря на то, что можно писать просто foo в конце документа, я продолжаю писать return foo. Мне нальют капучину в вашей старбаксе?
>> No.41539 Reply
>>41536
Foo.instance_methods(false) вернет методы без методов предков.
Еще можно так:
class Foo < String; def bar; end end 
=> nil 
a = Foo.new
=> "" 
a.methods - ''.methods
=> ["bar"]
> return foo
Если я жду, что метод вернет значение, пишу return, если неважно, опускаю.
Но однострочники намного лучше без return смотрятся: a.select {|n| n > 1}
>> No.41543 Reply
>>41536
Не надо опускать ретёрн, где попало. Гибкость руби, за которую его ругают, ожидает от программиста разумности. Я думаю, что возможность опускать его нужна для лямбд в первую очередь. В руби много, что можно опускать. Опускай только, если это разумно.
>> No.41546 Reply
>>41543
>>41539
Спасибо
>> No.41549 Reply
>>39358
Совсем другое. Денвер - пакет, чтобы искаропки у тебя все было настроено. Т.е. ты его устанавливаешь, и на твоей локальной машине уже и мускули и апачи и пэхапе. Или что там в денвер кладут.
>>39357
Вагрант полезен, чтобы не пердолиться при разработке с разворачиванием окружения для приложения. Смотри, допустим, тебе дали проект, который требует настроенной руби, какой-нибудь там постгре, еще-какую-нибудь хуиту, и на настройку/установку всего этого говна у тебя должно уйти в среднем час. Итого твой работодатель заплатит тебе за то, что ты целый час тупо разворачивал приложение. Ты его еще не запустил, а час уже спущен. Какой-то говно, не так ли? Плюс опять же, потом, при обновлении своих пакетов, ты будем в душе не ебать, на кой ляд тебе вся эта хуита нужна. Плюс эти вечные проблемы "посоны, но локально оно у меня работало, я гарантирую это".
Вагрант решает подобные проблемы. Ты просто начинаешь работать.
>> No.41564 Reply
>>41549
> Совсем другое.
Забавно, за это время я начал им активно пользоваться, а тут это пост всплыл.
>> No.43234 Reply
>>41543
Ретёрн не по стайлгайду. Его нужно опускать везде где это можно.
https://github.com/bbatsov/ruby-style-guide#no-explicit-return
https://github.com/arbox/ruby-style-guide/blob/master/README-ruRU.md#n[...]eturn
А возможность опускать ретёрн, это именно свойство философии языка.
>> No.43237 Reply
>>43234
По-моему странно немного, если идёт последовательность команда друг за другом и на последней команде нет ретёрн. Как-то не читается. Если тело состоит из одного выражения, то понятно, но если там именно последовательность идёт, то странно. Я не сильно против.
>> No.47981 Reply
Дорогие доброкодеры, не в качестве рекламы, но хотел бы показать вам свой сайт/блог с материалами по Ruby on Rails.

http://blog.topolyan.com/

Стараюсь писать качественные материалы, без рекламы.

Enjoy.
>> No.47996 Reply
Как стать успешным программистом

В этом посте я расскажу как стать успешным программистом и зарабатывать в долларах или евро.

1. Учишь Ruby, учишь Rails. Самый первый и важный пункт.

2. Изучаешь HTML/CSS/JS. Это должно быть легче.

3. Изучаешь AngularJS. Пригодится для разработки фронтенда.

4. Делаешь свой проект. Это будет проект, который ты будешь показывать работодателям или, как часть твоего портфолио, заказчикам.
Проект не обязательно должен быть коммерчески успешным или решать реальные проблемы, достаточно сделать всё грамотно и показать свои навыки.

5. Затем еще раз зубришь Ruby on Rails от корки до корки.

Теперь программировать ты умеешь, это уже хорошо, но ты еще не зарабатываешь.

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

6. Учишь английский. Если ты этого всё ещё этого не сделал, учи английский.

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

7(а). Отправляешь своё резюме в IT-компании. Можно искать напрямую или на сайтах типа AngelList.

7.(б). Регистрируешься на Upwork. Upwork это главная мировая фриланс-биржа. Труднее всего будет получить первые заказы, но потом пойдет как по маслу.

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

Оригинал: http://blog.topolyan.com/%d0%ba%d0%b0%d0%ba-%d1%81%d1%82%d0%b0%d1%82%d1%8c-%d1%83%d1%81%d0%bf%d0%b5%d1%88%d0%bd%d1%8b%d0%bc-%d0%bf%d1%80%d0%be%d0%b3%d1%80%d0%b0%d0%bc%d0%bc%d0%b8%d1%81%d1%82%d0%be%d0%bc/
>> No.47999 Reply
>>47996
Хрень какая-то, если честно.

Могу даже по пунктам расписать
>> No.48000 Reply
Зачем руби и рельсы. Они популяризировали это движение фреймворков и прочего. Сейчас мерты и не нужны, видимо прошлые легаси-модники раскошеливаются на этого редкого зверя.
Модно и дорого жс и всё его добро. Бэкенды можно писать как рест апи, очень удобно и лаконично.
>> No.48001 Reply
>>48000
На бэкэнде всё что угодно лучше яваскрипта, даже пхп.
>> No.48002 Reply
>>48001
Я и не имел в виду обязательно бэкэнды на жс, а морды. Каждый дрочит как он хочет.
>> No.48003 Reply
>>48002
Из-за того что js неимоверно уёбищен на фронтэнде используют всякие dart, kotlin, typescript, coffeescript, purescript, livescript, тысячи их.
>> No.48004 Reply
>>48003
У него было трудное детство, лол. Пилят, скоро будет достаточно ванили.
>> No.48005 Reply
>>48004
Но бабель всё равно прикручивать придется, потому что какие-нибудь версии ишака или сафари не будут уметь этот свежайший js.
>> No.48007 Reply
>>47996

>>1. Учишь Ruby, учишь Rails. Самый первый и важный пункт.
На этом можно и закончить.

Но нет.
>>2. Изучаешь HTML/CSS/JS. Это должно быть легче.
Нет это не будет легче. Это будет такая же долгая дорога, как и рейлс. На то и другое одновременно тебя не хватит. Если ты под учить не подразумеваешь 3.5 тэга с в3скулс.

>>3. Изучаешь AngularJS. Пригодится для разработки фронтенда.
Нах ты тогда учил css и тд? Сразу бы выбрал angular material или что там.
И да, что значит "пригодится" ? Пригодятся только памперсы и доширак, пока ты будешь 24/7 говнокодить. И да, оно не такое простое в теории. Так что это третья параллельная дорога, наряду с рейлс и говностеком.

> > 4. Делаешь свой проект. Это будет проект, который ты будешь показывать работодателям или, как часть твоего портфолио, заказчикам.Проект не обязательно должен быть коммерчески успешным или решать реальные проблемы, достаточно сделать всё грамотно и показать свои навыки.

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

>>5. Затем еще раз зубришь Ruby on Rails от корки до корки.Теперь программировать ты умеешь, это уже хорошо, но ты еще не зарабатываешь.Большинство твоих клиентов, скорее всего, будут англоязычными.

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

>>6. Учишь английский. Если ты этого всё ещё этого не сделал, учи английский.
> > На этом этапе теоретических знаний у тебя достаточно, так что можно приступать к поиску работы или фрилансу.

Каким боком это сюда попало?

>>7(а). Отправляешь своё резюме в IT-компании. Можно искать напрямую или на сайтах типа AngelList.

Никому нафиг твое голое резюме не нужно. Доллары и евро не потекут.

>>7.(б). Регистрируешься на Upwork. Upwork это главная мировая фриланс-биржа. Труднее всего будет получить первые заказы, но потом пойдет как по маслу.

А потом настанет коммунизм.

> > Через полгода ты выйдешь на приличный доход, возможно в разы или даже на порядок больше среднего по твоей локации.

Это сколько? Что значит приличный в твоем понимании? Сам-то хоть на пиво заработал?
>> No.49992 Reply
Неожиданный бамп!
>> No.49993 Reply
>>49992
УДОЛИ


Password:

[ /tv/ /rf/ /vg/ /a/ /b/ /u/ /bo/ /fur/ /to/ /dt/ /cp/ /oe/ /bg/ /ve/ /r/ /mad/ /d/ /mu/ /cr/ /di/ /sw/ /hr/ /wh/ /lor/ /s/ /hau/ /slow/ /gf/ /vn/ /w/ /ma/ /azu/ /wn/ ] [ Main | Settings | Bookmarks | Music Player ]