Pregunta

Estoy empezando a aprender ruby.Yo también soy de un día-a-día C++ dev.Para los proyectos de C++ normalmente voy con la siguiente estructura de directorios

/
 -/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 que dir diseño para Ruby (no Rieles, no Merb) sugeriría usted para mantenerlo limpio, simple y fácil de mantener?

¿Fue útil?

Solución

Bundler incluye la infraestructura necesaria para generar una joya:

$ bundle gem --coc --mit --test=minitest --exe spider
Creating gem 'spider'...
MIT License enabled in config
Code of conduct enabled in config
      create  spider/Gemfile
      create  spider/lib/spider.rb
      create  spider/lib/spider/version.rb
      create  spider/spider.gemspec
      create  spider/Rakefile
      create  spider/README.md
      create  spider/bin/console
      create  spider/bin/setup
      create  spider/.gitignore
      create  spider/.travis.yml
      create  spider/test/test_helper.rb
      create  spider/test/spider_test.rb
      create  spider/LICENSE.txt
      create  spider/CODE_OF_CONDUCT.md
      create  spider/exe/spider
Initializing git repo in /Users/francois/Projects/spider
Gem 'spider' was successfully created. For more information on making a RubyGem visit https://bundler.io/guides/creating_gem.html

Luego, en lib/, crear módulos como sea necesario:

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

Lea la página de manual de paquete de gemas para más detalles sobre la --coc, --exe y --mit opciones.

Otros consejos

A partir de 2011, es común el uso de joyero en lugar de newgem ya que éste es efectivamente abandonado.

La estructura básica de un estándar de Ruby proyecto 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 raro y es a veces llamada data/ en su lugar.Es de propósito general no ruby archivos.La mayoría de los proyectos no lo necesita, pero incluso cuando lo hacen muchas veces todo lo que se seguía en lib/, a pesar de que probablemente no es la mejor práctica.

El test/ directorio podría ser llamado spec/ si BDD se utiliza en lugar de TDD, aunque también es posible que vea features/ si el Pepino se utiliza, o demo/ si QED se utiliza.

En estos días foo.gemspec sólo puede ser .gemspec --especialmente si no está actualizado manualmente.

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

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

Además, la mayoría de Ruby del proyecto se tiene:

  Gemfile
  Rakefile

El Gemfile es para el uso de Bundler, y el Rakefile es para Rake herramienta de construcción.Pero hay otras opciones si desea utilizar diferentes herramientas.

Algunos otros no tan infrecuente archivos:

  VERSION
  MANIFEST

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

¿Qué otra cosa se puede ver, pero el uso es esporádico:

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

Donde config/ contiene varios archivos de configuración; doc/ contiene documentación que se genera, por ejemplo,RDoc, o a veces de forma manual mantenidos de la documentación; script/ contiene secuencias de comandos de shell para el uso por el proyecto; log/ contiene proyecto generado los registros, por ejemplo,prueba de informes de cobertura; pkg/ tiene generado el paquete de archivos, por ejemplo foo-1.0.0.gem; task/ podría mantener varios archivos de tareas tales como foo.rake o foo.watchr; vendor/ contiene copias de los otros proyectos, por ejemplo,git submódulos;y, finalmente, web/ contiene el proyecto del sitio web de los archivos.

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

  .document
  .gitignore
  .yardopts
  .travis.yml

Son bastante auto-explicativo.

Por último, quiero agregar que yo personalmente agregar un .index archivo y un var/ directorio de construir ese archivo (la búsqueda para "Rubyworks Alimentador" más acerca de eso) y a menudo tienen un work directorio, algo como:

  work/
    NOTES.md
    consider/
    reference/
    sandbox/

Sólo una especie de cementerio de coches para fines de desarrollo.

@Dentharg:su "incluyen uno para incluir todas las sub-partes" es un patrón común.Como todo, tiene sus ventajas (fácil conseguir las cosas que quieres) y sus inconvenientes (la incluye muchos pueden contaminar los espacios de nombres y usted no tiene ningún control sobre ellos).Su patrón se parece a esto:

- 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'
        ...

Yo te 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

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

No estoy seguro de a qué te refieres por un módulo, pero si sólo se trata de una sola clase de una carpeta independiente no sería necesario y si hay más de un archivo que normalmente escribe un módulo-1.rb archivo (en el nombre de nivel como el módulo-1 carpeta) que no hace nada más que requieren todo en el módulo-1/.

Ah, y me gustaría sugerir el uso de Rake para las tareas de administración (en lugar de hacer).

Yo me quedaría con algo similar a lo que usted está familiarizado con:no hay punto de ser un extraño en el directorio de tu proyecto.:-)

Típicas cosas que siempre se han lib|src, de reciclaje, de prueba.

(No me gusta este monstruo generadores:la primera cosa que quiero hacer con un nuevo proyecto es introducir el código de abajo, no escribir un README, docs, etc!)

Así que me fui con newgem.He quitado todas las RubyForge/gem cosas (azada, el programa de instalación, etc.), creado repositorio git, importado proyecto en NetBeans.Todos pasaron 20 minutos y todo en verde.Que incluso me dio un básico de la tarea de rake de las especificaciones de los archivos.

Gracias a todos.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top