Diseño del directorio para el proyecto Ruby puro

Question

Estoy empezando a aprender ruby. También soy un desarrollador diario de C++. Para proyectos de C++ por lo general van con estructura siguiente dir

/ 
-/bin <- built binaries 
-/build <- build time temporary object (eg. .obj, cmake intermediates) 
-/doc <- manuals and/or Doxygen docs 
-/src 
--/module-1 
--/module-2 
-- non module specific sources, like main.cpp 
- IDE project files (.sln), etc. 

Lo dir diseño para Ruby (no-rieles, no Merb) sugeriría usted para mantenerlo limpio, sencillo y fácil de mantener?

Answer 1

Usted puede instalar el rubygem newgem y dejar que genere el diseño para usted.

$ gem install newgem 
$ newgem spider 
     create 
     create config 
     create doc 
     create lib 
     create script 
     create tasks 
     create lib/spider 
     create History.txt 
     create License.txt 
     create Rakefile 
     create README.txt 
     create PostInstall.txt 
     create setup.rb 
     create lib/spider.rb 
     create lib/spider/version.rb 
     create config/hoe.rb 
     create config/requirements.rb 
     create tasks/deployment.rake 
     create tasks/environment.rake 
     create tasks/website.rake 
    dependency install_test_unit 
     create test 
     create test/test_helper.rb 
     create test/test_spider.rb 
    dependency install_website 
     create website/javascripts 
     create website/stylesheets 
     exists script 
     exists tasks 
     create website/index.txt 
     create website/index.html 
     create script/txt2html 
     force tasks/website.rake 
    dependency plain_theme 
     exists  website/javascripts 
     exists  website/stylesheets 
     create  website/template.html.erb 
     create  website/stylesheets/screen.css 
     create  website/javascripts/rounded_corners_lite.inc.js 
    dependency install_rubigen_scripts 
     exists script 
     create script/generate 
     create script/destroy 
     create script/console 
     create Manifest.txt 
     readme readme 
Important 
========= 

* Open config/hoe.rb 
* Update missing details (gem description, dependent gems, etc.) 

Luego, en lib /, se crea módulos según sea necesario:

lib/ 
    spider/ 
    base.rb 
    crawler/ 
    base.rb 
    spider.rb 
    require "spider/base" 
    require "crawler/base" 

Answer 2

¿Por qué no utilizar el mismo diseño? Normalmente no necesitarás construir porque no hay un paso de compilación, pero el resto me parece bien.

No estoy seguro de lo que quiere decir con un módulo, pero si se trata de una sola clase, no sería necesaria una carpeta separada y si hay más de un archivo normalmente escriba un archivo module-1.rb (en el nivel de nombre como la carpeta del módulo-1) que no hace más que requerir todo en el módulo-1 /.

Ah, y yo sugeriría usar Rake para las tareas de administración (en lugar de hacer).

Answer 3

@Dentharg: su "incluir uno para incluir todas las subpartes" es un patrón común. Al igual que cualquier otra cosa, tiene sus ventajas (es fácil obtener las cosas que quiere) y sus desventajas (los muchos incluyen pueden contaminar espacios de nombres y usted no tiene control sobre ellos). Su patrón es el siguiente:

- src/ 
    some_ruby_file.rb: 
     require 'spider' 
     Spider.do_something 

+ doc/ 

- lib/ 
    - spider/ 
     spider.rb: 
     $: << File.expand_path(File.dirname(__FILE__)) 
     module Spider 
      # anything that needs to be done before including submodules 
     end 

     require 'spider/some_helper' 
     require 'spider/some/other_helper' 
     ... 

Me podría recomendar esto para permitir un poco más de control:

- src/ 
    some_ruby_file.rb: 
     require 'spider' 
     Spider.include_all 
     Spider.do_something 

+ doc/ 

- lib 
    - spider/ 
     spider.rb: 
     $: << File.expand_path(File.dirname(__FILE__)) 
     module Spider 
      def self.include_all 
      require 'spider/some_helper' 
      require 'spider/some/other_helper' 
      ... 
      end 
     end 

Answer 4

que se pegaba a algo similar a lo que usted está familiarizado con: no hay punto de ser un extraño en su propio directorio del proyecto . :-)

Las cosas típicas que siempre tengo son lib | src, bin, test.

(No me gusta estos generadores de monstruos: la primera cosa que quiero hacer con un nuevo proyecto es conseguir un poco de código de abajo, no escribir una README, documentos, etc.!)

Answer 5

así que fui con newgem. Eliminé todas las cosas innecesarias de RubyForge/gema (azada, configuración, etc.), creé el repositorio git, proyecto importado en NetBeans. Todo tomó 20 minutos y todo está en verde. Eso incluso me dio una tarea básica de rake para archivos de especificaciones.

Gracias a todos.

Answer 6

A partir de 2011, es común usar jeweler en lugar de newgem ya que este último se ha abandonado efectivamente.

Answer 7

La estructura básica de un proyecto estándar de Ruby es básicamente:

lib/ 
    foo.rb 
    foo/ 
    share/ 
    foo/ 
    test/ 
    helper.rb 
    test_foo.rb 
    HISTORY.md (or CHANGELOG.md) 
    LICENSE.txt 
    README.md 
    foo.gemspec 

El share/ es rara y es a veces llamado data/ lugar. Es para archivos de uso general que no sean de rubí.La mayoría de los proyectos no lo necesitan, pero incluso cuando lo hacen muchas veces, todo se guarda en lib/, aunque probablemente esta no sea la mejor práctica.

El directorio test/ podría llamarse spec/ si BDD se está utilizando en lugar de TDD, aunque también se puede ver features/ si se utiliza pepino, o si se utiliza demo/ QED.

Actualmente, foo.gemspec puede ser .gemspec, especialmente si no se actualiza manualmente.

Si su proyecto tiene ejecutables de línea de comandos, a continuación, añadir:

bin/ 
    foo 
    man/ 
    foo.1 
    foo.1.md or foo.1.ronn 

Además, la mayor parte del proyecto de Ruby tiene:

Gemfile 
    Rakefile 

El Gemfile es para el uso de Bündler y el Rakefile es para Rake herramienta de construcción. Pero hay otras opciones si desea usar diferentes herramientas.

Algunos otros archivos no tan poco frecuentes:

VERSION 
    MANIFEST 

El archivo VERSION solo contiene el número de versión actual. Y el MANIFEST (o Manifest.txt) contiene una lista de archivos que se incluirán en los archivos del paquete del proyecto (por ejemplo, paquete de gemas).

¿Qué más podría ver, pero el uso es esporádico:

config/ 
    doc/ (or docs/) 
    script/ 
    log/ 
    pkg/ 
    task/ (or tasks/) 
    vendor/ 
    web/ (or site/) 

Dónde config/ contiene varios archivos de configuración; doc/ contiene documentación generada, p. RDoc, o en ocasiones documentación mantenida manualmente; script/ contiene scripts de shell para uso del proyecto; log/ contiene registros de proyectos generados, p. informes de cobertura de prueba; pkg/ contiene archivos de paquetes generados, p. foo-1.0.0.gem; task/ podría contener varios archivos de tareas como foo.rake o foo.watchr; vendor/ contiene copias de los otros proyectos, p. submódulos git; y finalmente web/ contiene los archivos del sitio web del proyecto.

A continuación, algunos archivos de la herramienta específica que también son relativamente comunes:

.document 
    .gitignore 
    .yardopts 
    .travis.yml 

Ellos son bastante fáciles de entender.

Por último, voy a añadir que, personalmente, añadir un archivo .index y un directorio var/ para construir ese archivo (búsqueda de "Rubyworks paso a paso" para más información sobre esto) y con frecuencia tienen una work directorio, algo así como:

work/ 
    NOTES.md 
    consider/ 
    reference/ 
    sandbox/ 

Simplemente una especie de depósito de chatarra para fines de desarrollo.