если попробую - скажу точнее )

ага, это называется convention over configuration.

ну тут есть... всякое... можно реально ужасы творить, никакой рельсовик приложуньку не узнает

так кажется первые 2-3 проекта

я тоже так думал

да! в этом поинт, от опыта зависит

а вот к чему приводит отсутствие фрэймворка с соглашениями - я это вижу в каждом первом проекте на ноде

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

а вот к чему приводит отсутствие фрэймворка с соглашениями - я это вижу в каждом первом проекте на ноде

да везде соглашения есть, даже в dry и ханами

и в кажлм тором - на php

ну вот я сделал достаточно большой проекк

меня наоборот эти соглашения по началу страшно бесили

по поводу dry - это крутые библиотеки, которые не вписываются в привычный путь разработки на рубях

да везде соглашения есть, даже в dry и ханами

и ты примерно знаешь, где модели в незнакомом проекте будут лежать?

проект один после работы за 2 месяца

приходится перучиваться полностью

и ты примерно знаешь, где модели в незнакомом проекте будут лежать?

ага

в ханами да, в dry-web тоже

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

и ты примерно знаешь, где модели в незнакомом проекте будут лежать?

в ханами они всегда в lib/project_name/* лежат

меня наоборот эти соглашения по началу страшно бесили

отрицание, гнев, торг, депрессия, принятие

в ханами они всегда в lib/project_name/* лежат

в куче с остальными файлами, которые тоже относятся к проекту?

в dry-web сложнее ибо там модели - это релейшены, репозитории и так далее

в куче с остальными файлами, которые тоже относятся к проекту?

не, там обычно бизнес весь лежит

модель, сервисы и все

не, там обычно бизнес весь лежит

а дай дерево файлов

сейчас еще мейлеры, но это не правильно и их перекинут в apps

с проекта какого-нито

https://github.com/ossboard-org/ossboard/tree/master/lib/ossboard

вот, сервисы, интеракторы, матчеры, модель

и кор либы

вот типичный app https://github.com/ossboard-org/ossboard/tree/master/apps/web

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

вот типичный app https://github.com/ossboard-org/ossboard/tree/master/apps/web

вот так выглядит API https://github.com/hanami/contributors/tree/master/apps/api

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

сервер не перезагрузился, например?

энжинкс - юникорн рестартовал руками.

ну надо только юникорн

сайт не мой. со всякими легаси конфигами, я не представляю где рыть.

юнткорн сам ребутится при деплое.

по идее да

в логах вижу.

но если старая версия отдается - первая мысль, что он не перезагрузился

в логах вижу.

а в какую папку нжинкс смотрит?

приходится перучиваться полностью

ну собственно, возвращаясь к этому. сейчас ханами - такой же mvc, как и рейлс. т.е. понять идеи основные не очень сложно. единственные 3 вещи, которые сильно отличаются: 1. валидация в экшенах, а не модели 2. ром для работы с бд (но мы активно доку пишем к этому) 3. амбрела архитектура (но по мне ее достаточно просто понять, т.е. это не рокет сайнс)

в логах вижу.

кэш проверь ещё

а в какую папку нжинкс смотрит?

include /etc/nginx/conf.d/*.conf; include /etc/nginx/sites-enabled/*;

include /etc/nginx/conf.d/*.conf; include /etc/nginx/sites-enabled/*;

это не папка

include /etc/nginx/conf.d/*.conf; include /etc/nginx/sites-enabled/*;

нинини, это папка конфигов

по public поищи в

а тебе нужен сам конфиг

так это из конфига строчки.

так это из конфига строчки.

в sites-enabled там конфиг, относящийся к твоему сайту

в sites-enabled там конфиг, относящийся к твоему сайту

вот такое там есть. # Application root, as defined previously root /home/deployer/имя_сайта/current/public; upstream app { # Path to Unicorn SOCK file, as defined previously s server unix:/home/deployer/имясайта/shared/tmp/sockets/unicorn.sock fail_timeout=0;

хм

вроде правильно

@gambala приди

вот такое там есть. # Application root, as defined previously root /home/deployer/имя_сайта/current/public; upstream app { # Path to Unicorn SOCK file, as defined previously s server unix:/home/deployer/имясайта/shared/tmp/sockets/unicorn.sock fail_timeout=0;

разве что имя_сайта и имясайта.

там нет случаем двух папок с немного отичающимися названиями?

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

ок

Странно, что перезапуск unicorn не помогает. У меня было как-то подобное, с юникорном как раз. Решалось двумя (!) перезапусками юникорна подряд

а иной раз - и двумя (!) ребутами (!) сервера подряд

в то время так и не понял в чем причина. сейчас перешел на puma, там такой проблемы нет

Странно, что перезапуск unicorn не помогает. У меня было как-то подобное, с юникорном как раз. Решалось двумя (!) перезапусками юникорна подряд

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

Как это это выглядит ужасновато

ERROR: S client not available

спасибо за помощь, Виталий и Теннпеннай. ребут сервера помог. видимо юникорн, тварь, действительно зависает где-то в процессах.

конечно лучше купить новый бентли чем заправить старый

полагаю что описаная проблема в юникорне решеается нормально без форса ребута

конечно лучше купить новый бентли чем заправить старый

ну прост старый бентли сломался,А новй так и не купили

он не сломался! его просто не заправили ?

он не сломался! его просто не заправили ?

сломался

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

не ну вы чо юникорн взрослый production-ready сервер не может он просто так не перезапускать детей

естессна

не ну вы чо юникорн взрослый production-ready сервер не может он просто так не перезапускать детей

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

отрепортил

кек

ну, есть же всякие студенты

когда я был студентом у меня не было денег на видюху для игр

не то что для майнига )

так что нефиг

https://stackoverflow.com/q/45418479/444079

548+

https://stackoverflow.com/q/45418479/444079

а как это относится к руби?

Hanami поддерживает ruby 2.4.1?

да

а как это относится к руби?

видимо носом ткнули, тип чё не помогаете

хеллбой вхож в более профильные чаты

https://eventil.com/presentations/1Gskd8

ваки завезли

если у меня включен CSRF, то хакер сможет отправить форму передав параметры в своем скрипте?

yep

а чо сразу хакер-то?

не сможет

ведь токена у него не будет

получит ошибку инвалидтокен