и вообще сложные вещи не пиши

лол

Тогда будет просто, это точн.

вообще не пиши ничео

и проблем не будет

сложные вещи писать моветон чем проще тем лучше всем, особенно бизнесу

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

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

и по коду даже не зареверсишь бизнесспроцесс.

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

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

Товарищи, не кто не сталкивался с проблемой что File.expand_path криво иногда работает?

Делаешь проще, если есть возможность вводишь баг систему любую.

и там issue делаешь по фичам.

Локально всё ок, на тестовой машине путь дает вообще от корня, а не от корня приложения

а в production env на локальной машине?

dev в обеих слуаях

ну а как ты дергаешь expand_path?

Converts a pathname to an absolute pathname. Relative paths are referenced from the current working directory of the process

Типа так Sablon.template(File.expand_path("public/template_parts.docx"))

current working directory of the process

Sablon - это типа шаблон?)

а, не, template processor для docx :)

https://github.com/senny/sablon

и в одном случае получаю /home/user/project/public/template_parts.docx а вдругом просто /public/template_parts.docx

current working directory of the process

Если не кто не сталивался то и хрен с ним, заменю на Rails.root так везде работает.

типа не под тем пользователем процесс запушен?

или пользователь дофига рутированный?)

тогда бы было of the user

Rails.root имхо неплохое решение.

Rails.root имхо неплохое решение.

я знаю, но мне просто интересно, почему не работает

ну я ж за тебя прочитал уже, и за тебя выбрал важное

current working directory of the process

Прошу прошения, действительно помогло. Причина в том что на дестовом стенде запушенно приложение как демон, т.е так rails s -d Если по обычному запускать то всё ок.

На тестовом стенде я бы под staging средой запускал, или вообще под production (иногда чревато)

и запускал бы максимально приближено к тому как оно будет на продакшене работать, таже среда, тот же софт.

хмхм можно конечно придумать кейс когда это будет чревато но не перебор ли?

На тестовом стенде я бы под staging средой запускал, или вообще под production (иногда чревато)

да, ваша правда, но всё не как руки не доходят нормально настроить

Типичный рельсовый проект очень быстро настраивается.

и потом просто через капистрано также быстро деплоится.

Оно того стоит.

Если staging в dev работает то можно словить на продакшене ошибки конфигурации которые в dev не видны.

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

Я к тому что это занимает совсем немного времени но того очень и очень стоит.

Если staging в dev работает то можно словить на продакшене ошибки конфигурации которые в dev не видны.

а, ступил, да

а, ступил, да

У меня постоянно такие кейсы были что в env'ах что то забыл добавить.

staging это как prod, только staging

Там правда легаси было, ссылки на апишку в env'ах пихали.

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

в смысле .rb не ENV.

В проекте нету капистраны? докер?

еще нужно запастись: "ничо не знаю парни, на стейдже работает!"

у меня CI через капистрану билд на staging выкатывал, лол.

Я ваше хз что на боевом стоит :)

еще нужно запастись: "ничо не знаю парни, на стейдже работает!"

Один фиг все ошибки до прода не выловишь, но их станет значительно меньше, да.

Я ваше хз что на боевом стоит :)

чет мне страшно стало. Как ты кодишь то?

у меня CI через капистрану билд на staging выкатывал, лол.

какой CI юзаете кстати

чет мне страшно стало. Как ты кодишь то?

а в крупных конторах часто джунам и иногда миддлам никто ни хера не говорит

вопрос не по теме. кто ставил PGP? OpenPGP

а в крупных конторах часто джунам и иногда миддлам никто ни хера не говорит

У каждого разраба свой тестовый. Ветка -> на свой тестовый -> если тестер принимает льётся в мастер -> опять теститься и потом на продакшон

свой стейдж - неплохо

Свой стейж? ого

Это наверное имеет смысл только в больших командах

какой CI юзаете кстати

У меня очень маленькая команда была ~4 человека. Нам gitlab-ci позаглаза хватало.

Он на мой взгляд вполне неплох.

Хз, свой тестовый весьма удобно, дешего и сердито

Зависит от размера команды

ERROR: S client not available

Ну и от флоу конечно же.

свой стейдж - неплохо

под каждый pull-request поднимать staging - ок

aws -> create instance

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

У меня очень маленькая команда была ~4 человека. Нам gitlab-ci позаглаза хватало.

Ну у нас примерно тоже самое, сейчас больше смотрю в сторону Drone IO

Он на мой взгляд вполне неплох.

мне тож нравится кстати

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

на каждый комит по стейджингу? :)

Не ну ты перебрал.

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

Я не работал в большой команде :(

у нас вот на каждого тестера по стейджу

Это более логичный подход

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

я думал себе из говнобука сделать, но как-то времени жалко

Тогда уж сразу в виртуалку на своем рабочем компе/ноутбуке деплоить

Виртуалку еще и перетаскивать между системами более менее удобно.

Тогда уж сразу в виртуалку на своем рабочем компе/ноутбуке деплоить

а смысле от виртуалки на рабоем компе. Прикол тестового для каждого разработчика в том что-бы новый функционал показать тестеру/заказчику/бабушке

а смысле от виртуалки на рабоем компе. Прикол тестового для каждого разработчика в том что-бы новый функционал показать тестеру/заказчику/бабушке

Каждый разработчик кому все будет показывать? тимлиду на каждый чих?

Тестеру

у нас вот на каждого тестера по стейджу

Оригинально, но лучше на каждую фичу по стейджу, кмк.

Тестеру

серьезно? каждый разработчик тестеру отвечает?

А не тестится ли все это на стейжинге перед релизом?

А не тестится ли все это на стейжинге перед релизом?

Нет. У тебя одна не рабочая фича весь релиз блокировать будет?

На релиз же отводится какое то время. Одна фича так много времени займет на исправление?

На релиз же отводится какое то время. Одна фича так много времени займет на исправление?

Но проще же вообще этого избегать.

Ты предлагаешь каждую фичу на собственном стейжинге каждому из 10 разработчиков показывать?

яж показывал уже http://theclassicalcomposers.com

Так вроде все, кроме Easy ошибку выдаёт

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

Так вроде все, кроме Easy ошибку выдаёт

Хм. Проверю. Спасибо

Ты предлагаешь каждую фичу на собственном стейжинге каждому из 10 разработчиков показывать?

Нет, конечно. Для тестирования руками тестеров.

Но, да. Под каждую фичу свой тестовый стенд поднимается.

Мне кажется это не эффективно. Это действительно работает?