Alors qu'elle doit présenter prochainement son nouvel équipage d'astronautes qui embarquera pour l'ISS, l'agence gouvernementale de l'aéronautique et de l'espace vient de dévoiler les équipes finalistes qui ont été sélectionnées grâce au concours 3D Printed Habitat Challenge.
Débuté en 2015 par la Nasa en partenariat avec l'Université de Bradley, le concours réunissait 18 équipes provenant du monde entier dans l'objectif de trouver le meilleur projet de conception d'habitats capables de résister extrêmes de la planète Mars.
You may be creating more and more scripts for your systems, which need to use the same functions.
You already mastered the ancient art of copy-paste, but you are not satisfied with the result.
You probably know lots of Perl modules that allow you to use their functions and you also want to create one.
However, you don't know how to create such a module.
Recommended Project Layout
In order to avoid problems with syntax validation (such as packages reported missing) and the debugger (such as skipped breakpoints), it is best to organize your project according to the conventions of the core Perl distribution:
Keep your own modules in dedicated subtrees of your project. For example, create a subdirectory lib as the root of the subtree containing all *.pm files. Note that you can have more than one such subtree. For example, you could also create test/lib to store modules that are only imported by test scripts.
Add the root directories of your subtrees to the @INC path (see the section called “Perl Include Path”). For example, add the entries lib and test/lib there.
Map package names to paths in the subtree (and vice versa). For example, store code for the package Foo::Bar in file lib/Foo/Bar.pm and ensure that lib/Foo/Baz.pm contains only package Foo::Baz.
Store your Perl scripts anywhere you like in the project. For example, in subdirectory bin or cgi-bin.
To import from a package, use it, rather than require it. For example, use Foo::Bar; rather than require '../lib/Foo/Bar.pm';