Jak skonfigurować podstawowy projekt Ruby?

Chcę stworzyć mały projekt Ruby z 10 ~ 20 klasami / plikami. Potrzebuję perełek i chcę używać RSpec jako struktury testowej.

Mogę później zbudować klejnot, ale to nie jest pewne.

Czy jest jakaś instrukcja lub przewodnik, który pokazuje mi, jak skonfigurować podstawową strukturę mojego projektu?

Pytania, które mam, to:

• Gdzie mogę umieścić wszystkie moje niestandardowe błędy / wyjątki?
• Czy istnieją jakieś konwencje nazywania katalogów, takich jak lib, bin, src itp?
• Gdzie umieścić dane testowe lub dokumenty?
• Gdzie potrzebuję wszystkich moich plików, aby mieć do nich dostęp w moim projekcie?

Wiem, że mógłbym zrobić wszystko od zera, ale chciałbym uzyskać wskazówki. Istnieje kilka dobrych perełek, które mógłbym skopiować, ale nie jestem pewien, czego naprawdę potrzebuję, a co mogę usunąć.

Spojrzałem na http://gembundler.com/ , ale zatrzymuje się po skonfigurowaniu Bundlera.

Na dobry początek możesz użyć bundle gempolecenia i rspec --init.

~/code $ bundle gem my_lib
      create  my_lib/Gemfile
      create  my_lib/Rakefile
      create  my_lib/LICENSE.txt
      create  my_lib/README.md
      create  my_lib/.gitignore
      create  my_lib/my_lib.gemspec
      create  my_lib/lib/my_lib.rb
      create  my_lib/lib/my_lib/version.rb
Initializating git repo in /Users/john/code/my_lib
~/code $ cd my_lib/
~/code/my_lib $ git commit -m "Empty project"
~/code/my_lib $ rspec --init
The --configure option no longer needs any arguments, so true was ignored.
  create   spec/spec_helper.rb
  create   .rspec

• kod wchodzi lib
• specyfikacje wchodzą spec
• wprowadzane są dane testowe lub dokumenty spec/fixtures/
• Wymagaj wszystkich plików ruby ​​w formacie lib/my_lib.rb. Możesz zdefiniować swoje wyjątki również w tym pliku lub w ich własnych plikach - zgodnie z własnymi preferencjami.
• Pliki źródłowe C wchodzą do ext/my_lib
• skrypty powłoki i pliki wykonywalne wchodzą do środka bin

W razie wątpliwości spójrz, jak ułożone są inne klejnoty.

Dalsza informacja:

Powinieneś dodać rspec jako zależność programistyczną w swoim gemspec, aby ułatwić pracę innym programistom

1. Edytuj my_lib.gemspec, dodając gem.add_development_dependency 'rspec'i gem.add_development_dependency 'rake'u dołu.
2. Dodaj Bundler.setupi require 'my_lib'na początku specyfikacji / spec_helper.rb, aby upewnić się, że zależności klejnotów są ładowane po uruchomieniu specyfikacji.
3. Dodaj require "rspec/core/rake_task"i task :default => :specdo swojego Rakefile, aby uruchomienie rakeuruchomiło Twoje specyfikacje.

Podczas pracy nad najnowszym dziełem guard-rspec może zaoszczędzić czas i kłopotów, automatycznie uruchamiając specyfikacje w miarę zmiany plików, ostrzegając o awariach specyfikacji.

~/code/my_lib $ git add spec/spec_helper.rb
~/code/my_lib $ git commit -am "Add RSpec"
~/code/my_lib $ vim my_lib.gemspec # add guard development dependency
~/code/my_lib $ bundle
~/code/my_lib $ bundle exec guard init
~/code/my_lib $ vim Guardfile # Remove the sections below the top one
~/code/my_lib $ git add Guardfile
~/code/my_lib $ git commit -am "Add Guard"

Gdy będziesz zadowolony ze swojego dzieła, przenieś je na github

# create a github repository for your gem, then push it up
~/code/my_lib $ curl -u myusername https://api.github.com/user/repos -d '{"name":"my_lib"}' 
~/code/my_lib $ git remote add origin git@github.com:myusername/my_lib.git
~/code/my_lib $ git push

Następnie, gdy będziesz gotowy, aby wydać swój klejnot na Rubygems.org, biegnij rake release, co poprowadzi Cię przez kolejne kroki.

~/code/my_lib $ rake release

Dalsze odniesienia

• Przewodnik po wzorach Rubygems (i strona główna ), z odpowiedzi Matheusa Moreiry. To naprawdę świetne referencje
• Jak zaczynam? Steve Klabnik
• Ćwiczenie 46: Szkielet projektu z książki Learn Ruby The Hard Way Zeda Shawa
• Nowy film Gem z Bundlerem na Railscasts
• dokumenty

Na rubygems.org jest kilka fajnych przewodników , które wprowadzą Cię w konwencje i uzasadnienie niektórych z nich. Ogólnie rzecz biorąc, większość programistów Ruby przestrzega konwencji nazewnictwa i katalogów Rubygems .

Utworzyłbym niestandardowe klasy wyjątków tylko wtedy, gdybym nie był w stanie znaleźć żadnej klasy w bibliotece standardowej, która pasuje do opisu błędu. Zagnieżdż swoją klasę błędów pod klasą lub modułem, który ją podnosi:

class Parser::Error < RuntimeError; end

begin
  Parser.new(:invalid).parse!
rescue Parser::Error => e
  puts e.message
end

Testy jednostkowe przechodzą do /test, jeśli używasz Test::Unit, lub do, /specjeśli używasz RSpec. Polecam to drugie.

Bundlerto świetny sposób na zarządzanie ścieżką ładowania. Automatycznie skonfiguruje twoje środowisko tylko z zależnościami określonymi w Gemfilei opcjonalnie gemspec. Umożliwia także łatwe tworzenie requirekodu bez robienia z niego klejnotu.

Ponieważ jednak w przyszłości możesz spakować swój kod w klejnot, zalecam zbadanie sposobu tworzenia specyfikacji klejnotów . Specyfikację należy napisać ręcznie. Nie używaj jakiegoś narzędzia do automagicznego generowania go - moim zdaniem są to podejścia brutalnej siły, które niepotrzebnie duplikują informacje i sieją spustoszenie, gdy są używane z kontrolą źródła.

Stworzyłem klejnot, który może ci się przydać. Biorąc pod uwagę gemspecplik, definiuje wiele przydatnych Rakezadań do pracy z twoim klejnotem, w tym zadania związane z budowaniem, instalowaniem i wydawaniem twojego klejnotu rubygemsi gitrepozytorium z automatycznym oznaczaniem wersji. Zapewnia również łatwy sposób załadowania kodu w sesji irblub pry.

# Rakefile
require 'rookie'

# Run `rake -T` for the complete task list
Rookie::Tasks.new('your_gem.gemspec').define_tasks!

Oto konwencje, które najczęściej widziałem (zakładając, że nazwa twojego projektu to „foo”):

• /lib/foo.rb - definiuje przestrzeń nazw najwyższego poziomu projektu i jej wersję; wymaga potrzebnych plików.
• / lib / foo / - zawiera wszystkie klasy dla twojego projektu, w tym klasy związane z błędami.
• / test / - zawiera testy dla twojego projektu.
• / spec / - zawiera specyfikacje twojego projektu.
• / bin / - Jeśli Twój projekt zależy od plików binarnych (pliki JAR itp.), zwykle są one tam umieszczane.

Wewnątrz lib / konwencja polega zwykle na utworzeniu folderu dla każdej podprzestrzeni nazw wewnątrz przestrzeni nazw najwyższego poziomu. Na przykład klasa Foo :: Bar :: Baz znajduje się zwykle w katalogu /lib/foo/bar/baz.rb.

Niektórzy lubią tworzyć plik /lib/foo/version.rb tylko po to, aby ustawić stałą Foo :: VERSION, ale bardzo często widziałem to zdefiniowane w pliku /lib/foo.rb.

Ponadto, jeśli tworzysz klejnot, będziesz potrzebować następujących plików:

• / Rakefile - Definiuje zadania rake (takie jak zadania testowania, budowania i przesuwania klejnotu).
• / Gemfile - określa źródło klejnotu (między innymi).
• /foo.gemspec - opisuje twój klejnot i dostarcza listę zależności.

W Internecie jest kilka poradników na temat struktury projektu Ruby. Poza tym myślę, że najlepszym sposobem rozwiązania tego problemu jest przejście na github i poszukanie jakiegoś słynnego projektu Ruby i sprawdzenie "ich" struktur.

Oprócz ogólnych wymagań dotyczących rubinowych klejnotów, polecam następujące narzędzia dla lepszego przepływu pracy:

• editorconfig , pomaga programistom definiować i utrzymywać spójne style kodowania między różnymi edytorami i IDE.
• rubocop , statyczny analizator kodu dla Ruby, defac to linter w społeczności Ruby.
• guard , wraz z kilkoma wtyczkami, możesz automatycznie uruchamiać dowolne polecenia, gdy kod się zmienia.
• rake , uniwersalny sterownik do różnych zadań projektowych, takich jak:
  • package: zbuduj pakiet klejnotów
  • clean: wyczyść wygenerowane pliki
  • test: uruchom test
• yard , popularne narzędzie do dokumentacji ruby.

Poza wszystkimi powyższymi narzędziami, ich usługa online dla projektu Ruby:

• CI (ciągła integracja)
  • travis-ci
  • cirleci
  • kod pocztowy
• Przegląd kodu
  • kodeklimat

Możesz nawet generować odznaki przez http://shields.io/ dla swojego projektu open source.

To moje doświadczenie, mam nadzieję, że komuś pomoże.