Przeważnie trzymam swoje projekty na githubie ze względu na wygodę. W Django jak miałem coś w konfigu co było niejawne, to po prostu trzymałem to w osobnym pliku + .gitignore i ładowałem dane z pliku na początku przetwarzania ustawień przez django.
W RoR ogólnie prawie wszystko jest implicit a nie explicit i dobrze jest się trzymać dosyć sztywno narzuconych konwencji jeżeli chce się myśleć o dzieleniu/publikacji kodu… stąd pytanie: jak wczytywać niejawne ustawienia, takie jak np. hasło do serwera smtp czy np. klucz do jakiegoś API?
Niejawny config wczytuj z ENV czyli np. w .bashrc eksportujesz jakąś zmienną i potem z ENV ją zczytujesz. W tym momencie jest to obojętne czy użyjesz secrets.yml (osobiście nie przepadam za tym plikiem, bo to rozwiązanie jest niedopracowane). czy skorzystasz z zewnętrzego gema do configu, czy napiszesz własny moduł/klasę wykorzystującą ActiveSupport::Configurable
nie chce robić offtopa ale jak nie ma argumentów przeciw, to jakie są argumenty za ? W linuxie nie będziesz mógł używać wielu gemów, które korzystają z funkcji linuksowych, a które często wykorzystywane są w różnych aplikacjach.
Bo projekty na studia w C++/C# piszę w Visual Studio. Windowsa znam na wylot i skoro nie spotkałem żadnego większego problemu z developerką w Rubym pod Windowsem. Do tego jedyny sposób, żeby virtualna maszyna działała mi na obu monitorach to jest tryb full screen. W takim trybie nie przełączę się alt+tab do innego windowsowego programu, chociażby żeby przeskoczyć kawałek którego nie lubię na płycie. Można by długi wymieniać… ale prawda jest taka że to jest kwestia przyzwyczajenia. Pod Windowsem nie muszę się zastanawiać jak coś zrobić Ja widzę same plusy.
Gemy… napisz mi proszę które, tera nie kpię, tylko naprawdę się nie spotkałem z takimi gemami. Może link do jakiegoś projektu na githubie? Naprawdę chętnie to sprawdzę to w domu.
PS. Ja ogólnie póki co jestem hobbystą, przede wszystkim Pythonistą. Z Pythonem różni ludzie mi kiedyś wmawiali, że coś tam nie będzie działać pod windowsem, ale zawsze się okazywało że problem polega jedynie na tym, że trzeba “ręcznie” skompilować binarne rozszerzenia z których dana biblioteka korzystała. Np. Matplotlib czy PyQT, ale i tak w 95% przypadków są dostępne binarne instalki. A z PyQT to dopiero jest jazda, stara wersja z pakietów pod Linuxem działa bezbłędnie, ale spróbuj to ściągnąć, skompilować ze źródeł, poprawnie zainstalować i gdzieś użyć…
Ale wracając do tematu. @sharnik: jeśli nie ENV to co?
Zbyt literalnie do tego podchodzisz. Chodzi o to by nie przechowywać globalnego stanu, który w jednym miejscu jest modyfikowany, a w innym odczytywany. Natomiast każda aplikacja taki globalny stan posiada i są niby choćby klasy i moduły. Konfiguracja jest stanem, którego normalna aplikacja nie zmienia w trakcie działania więc nie ma tak na prawdę różnicy czy jest to wyciągane przez AppConfig.foo czy też ENV[‘foo’].
Zgodzę się całkowicie z tym co piszesz, jeśli dodamy Twoje ciche założenie o jednej aplikacji na jednym serwerze.
Jeśli masz więcej aplikacji, to masz globalny stan, które jedne aplikacje modyfikują (zapisując swoje zmienne przy deploy’u), a inne odczytują. Jeśli masz jakis konflikt nazw między dwoma projektami (albo konfiguracjami staging/preview) na tym samym serwerze, to życzę miłego debugowania.
U mnie używamy pilków konfiguracyjnych, dla dev/staging/preview trzymanych razem z aplikacją w repo, a dla produkcji generowanych przy deploy’u. Głównie dlatego, że ENV u nas po prostu nie ma prawa działać, bo używamy monit do wskrzeszania padniętych procesów, a on czyści wszystkie zmienne środowiskowe.
Nie mów, że trzymasz wszystkie aplikacje na jednym koncie użytkownika. Jak na serwerze ma się kilka aplikacji to prawidłowych podejściem jest jedno konto użytkownika na jedną aplikację.
Jakoś sobie nie wyobrażam, żeby haseł dla produkcji trzymać w repo.
my używamy Goda, a on radzi sobie dobrze ze zmiennymi środowiskowymi
[quote=“wafcio, post:17, topic:8572”]
Jakoś sobie nie wyobrażam, żeby haseł dla produkcji trzymać w repo.
[/quote]A gdzie je trzymasz w takim razie, żeby automatycznie dostawić nowy serwer?
Na razie nie miałem okazji automatycznego dostawiania nowego serwera. Trzeba było od tego zacząć, teraz to nabiera sensu. Nie każdy projekt wymaga automatycznego dostawiania nowego serwera.
