As we all know, the common structure of rubygem assumes presence of lib directory. I noticed, that generally in this directory are two items: gem_name.rb and gem_name/ directory. The gem_name/ directory hold main sources of project. It is heart of application. So, the question is about gem_name.rb file. What does it stand for?
The reason it's structured like that is if you had files other than gem_name.rb in the lib/ directory (say another_file_name.rb), you'd be liable to cause problems if there was a gem with the name another_file_name and someone did require another_file_name - it'd load your file, rather than the other gem's file.
If your code is small enough it can all fit into gem_name.rb, then put it there, otherwise put it into gem_name/other_file_name.rb.
Typically that just requires everything from the gem_name/ directory that's needed. It's used to keep all the requires in a central location and separate from the actual code
Related
I'm on OS-X (Mavericks, if that matters), and I'm making a bash script that will use resources from a folder called "templates". I'm trying to figure out where I should put it (the templates folder). I'd like to make it so the user doesn't need to modify their path when they install it, so I'd rather not do it the way the terminal mysql command does it (it lives in a folder in /usr/local/mysql/bin). I really want to be able to put them into usr/bin, but I don't know if it's "polite" to put folders in there (I don't see any in there).
Right now I'm leaning towards putting the scripts in usr/bin and having the templates in usr/lib. Is that how this type of thing is normally done, or is there another way? I'd like to follow a convention, assuming there is one. I'd also like it to apply to as many Unix platforms as possible (I'd like to put in a directory where bash scripts live that's consistent across as many Unix platforms as possible). Thanks.
If you follow the Filesystem Hierarchy Standard (FHS), your executable goes in /usr/local/bin, while read-only template files go in /usr/local/share/YOURAPP/. To quote the FHS:
/usr/local/share
The requirements for the contents of this directory are the same as /usr/share. […]
and:
The /usr/share hierarchy is for all read-only architecture independent data files.
(Emphasis added)
If the system admin is meant to customize the template files to take effect system-wide, then they would simply go in /etc/YOURAPP/templates (or something like that).
If the template files are customized on a per-user basis, then the modified copies of the templates (copied from /usr/local/share/YOURAPP/templates) need to be saved in the user's directory, under $HOME/.config/YOURAPP/templates or something like that (thanks to technosaurus for the correction).
You mentioned that you want to install the templates in a directory alongside your executable. That is not the standard approach on UNIX, at least going by the FHS. If you really want to go this route, there is a sort of convention of installing your app to /opt/YOURAPP/, using whatever organization you want inside that folder.
In all cases, it is not good practice to install executables directly to /usr/bin, as that directory is considered to be under the exclusive control of the OS/distribution. If you want to install there, the accepted way to do that is to create a package for the package manager of every supported OS/distribution.
I have just started using cucumber and am seeking clarification whether the folder having my step definitions must be named exactly as step_defnitions or can it be anything (e.g. my_defs). I tried renaming in my local machine but sometimes it works and sometimes doesn't.
features/
|
|-- step_definitions/
Cucumber will automatically load any files within the features folder. This means that your step definition files can be located in any folder name/structure as long as they are in the features folder.
Note that it is possible to override this setting and explicitly state the location of your steps by doing:
cucumber -r your/steps/folder/location
For more details you can see the help - cucumber -h:
-r: Require files before executing the features. If this option is not specified, all *.rb files that are siblings or
below the features will be loaded auto-matically. Automatic loading is
disabled when this option is specified, and all loading becomes
explicit. Files under directories named "support" are always loaded
first. This option can be specified multiple times.
In every reference I've seen (including the RSpec Book), they always have a "step_definitions" folder for definitions. A lot of things in Ruby (and especially Rails) utilize a "convention over configuration" philosophy, and I believe this is one of those things. I think it'd be less hassle for you to just make the "step_definitions" folder inside the "features" folder and know that it should work than to try and figure out how to change the configuration.
My application uses json configuration files and other resources. Where should I place them in my project hierarchy?
I could not find the answer in http://golang.org/doc/code.html (How to Write Go Code)
Upd:
The question is not about automatic distribution of resources with application but much simpler: Where should I keep my resources in project hierarchy? Is there some standard place anyone expects them to be?
There is no single correct answer, nor are there any strong conventions assumed or enforced by any Go tooling at this time.
Typically I start by assuming that the files I need are located in the same directory from where the program will be run. For instance, suppose I need conf.json for myprog.go; then both of those files live together in the same directory and it works to just run something like
go build -o myprog && ./myprog
When I deploy the code, the myprog binary and conf.json live together on the server. The run/supervisor script needs to cd to that directory and then run the program.
This also works when you have a lot of resources; for instance, if you have a webserver with JS, CSS, and images, you just assume they're relative to cwd in the code and deploy the resource directories along with the server binary.
Another alternative to assuming a cwd is to have a -conf flag which the user can use to specify a configuration file. I typically use this for distributing command-line tools and open-source server applications that require a single configuration file. You could even use an -assets flag or something to point to a whole tree of resource files, if you wanted.
Finally, one more approach is to not have any resource files. go-bindata is a useful tool that I've used for this purpose -- it just encodes some data as bytes into a Go source file. That way it's all baked into your binary. I think this method is most useful when the resource data will rarely or never change, and is pretty small. (Otherwise you're going to be shipping around huge binaries.) One (kind of silly) example of when I've used go-bindata in the past was for baking a favicon into a really simple server which didn't otherwise require any extra files besides the server binary.
For static resource it might be the most convenient solution to include them in the binary similar to resources in Java. Newer Go version, at least 1.18 are providing the //go:embed directive to include content:
import (
_ "embed"
)
//go:embed myfile.txt
var myfile string
You can now use myfile in your code. E.g. IntelliJ provides also support for this.
There are also other options to include the content, e.g. as binary or dynamically, see the link.
I did a bit of searching and found this thread on the topic but it's specific to XML files, and so the answer makes sense (/etc/) for XML files.
In my case, I'm actually storing a txt file, which happens to be an SVN version number that I dumped out within my modman script.
The place that I'm using this is within a frontend model (Blocks/System/Html.php) which outputs the version number within the module config. So I went with the Blocks/System/ directory for now - the filename is Version.txt - but it feels like there should be a better place to put this.
Since this SVN version number is being written by an external tool I would prefer it not mess with the contents of code directories (which in a live environment may have write restrictions) and instead have it write to the "var" directory. In which case to get the correct path within "var" you would use:
$fullpath = Mage::getBaseDir('var') . DS . $path;
The contents of "var" are disposable, they may be deleted at any time so be prepared for a missing file.
version numbers can be added to app/code/local/Your/Extension/etc/config.xml
<config>
<modules>
<Your_Extension>
<version>0.0.0.0</version>
</Your_Extension>
</modules>
</config>
magento knows how to handle your extension version changes and can call update scripts based on version number change. This is the preferred method for this kind of stuff.
if you need to add random non php classes files to your extension then add them to your extension folder and ask them from there:
Mage::getModuleDir('etc', 'Your_Extension');
Mage::getModuleDir('whateverfolder', 'Your_Extension');
This is not a good practice though as this might just break magento compilation feature or introduce other issues so it is better to handle external data also through php classes or xml files inside your extension structure
I ran into the same kind of problem when developing a shipping module. I had a bunch of CSV files that contained maximum weight / delivery cost mappings. For what it's worth, I created a data/ directory at the module level and threw everything in there.
I don't think this kind of situation doesn't happens often enough in the Magento codebase for there to be an established convention. As long as you use sensible naming, and provide a level of abstraction to cope with any change of file location in the future, I'd say put it in any folder at your module's root.
As I create more applications, my /code/shared/* increases.
this creates a problem: zipping and sending a project is no longer trivial. it looks like my options are:
in Xcode set shared files to use absolute path. Then every time I zip and send, I must also zip and send /code/shared/* and give instructions, and hope the recipient doesn't have anything already at that location.
this is really not practical; it makes the zip file too big
maintain a separate copy of my library files for each project
this is not really acceptable as a modification/improvements would have to be implemented everywhere separately. this makes maintenance unreasonably cumbersome.
some utility to go through every file in the Xcode project, figure out the lowest common folder, and create a zipped file structure that only contains the necessary files, but in their correct relative folder locations, so that the code will still build
(3) is what I'm looking for, but I have a feeling it doesn't as yet exist.
Anyone?
You should rethink your current process. The workflow you're describing in (3) is not normal. This all sounds very complicated and all basically handled with relative ease if you were using source control. (3) just doesn't exist and likely never will.
A properly configured SCM will allow you to manage multiple versions of multiple libraries (packages) and allow you to share projects (in branches) without ever requiring zipping up anything.