As usual, this is probably my fault for giving too much context. If you're trying to compose an answer to my question, kindly try again.
The question is almost entirely, Where do I put my files? I'm not looking for tools; I've got a good selection. I'm not looking for project management philosophies like Agile or Rapid. I want to know how to set up a working tree of folders and files and how to convert that into the various other trees that must be created.
Please reference one or possibly two books or comprehensive net resources that you personally find useful in explaining project file management. I strongly prefer resources that relate directly to Linux, Perl, and Git. I'm not so interested in abstractions; I want concrete, specific instructions. References of the form <isbn://0-684-84328-5> are probably best. I'll take it up from there. Author/title or amazon.com or oreilly.com links are okay too. Pick a book and I can find it. If you think the best available reference is online, link me, or at least name it.
Again: Please don't try to answer this question directly in a reply node. I'm looking for references you trust. I don't expect anyone to build me up a custom solution and I'm sure I have a great deal to learn. I must roll up my sleeves, burn the midnight oil, study-up, and dig deeper into the cliche bin.
If you're trying to understand why I'm asking you, it's because, by and large, I think Monks are the most reliable source of information on Perl topics. I can, and have, staggered back from the bookstore, hundreds of dollars poorer; and having studied my booty, sat deflated and ignorant. Usually, I don't retain too much bad advice but that's happened, too.
I've been researching the topic, heavily and for some time, on my own. I'm not happy with my results.
Here are examples of comments made which, in reply, should be avoided; and why:
... just take an existing distribution and modify it... -- Almost by definition, the distribution is not the working tree. I don't want a plate of ribs; I want the barbecue sauce recipie. Actually, all I want in replies here is a link to your favorite cookbook.
... a comprehensive work on the overall topic. ... doesn't exist... -- I suspect there are hundreds, thousands of such works. You may, of course, think that they are all wrong.
...you do it the way everyone else does - i.e., standard project management techniques appropriate for the level at which you do your work... -- Great idea. Where are these standard techniques documented?
...I don't think that the answer you're looking for exists - at least not in any way that can be conveyed in a post (or even in a thick book)... -- I'm damn sure it can't be contained in a post, which is why these paragraphs of philosophy puzzle me. If I need to read half a dozen books, I'll just have to plan on more time. I'm not looking to become a project management expert but I'd like to learn enough to keep from screwing myself every time I touch a file.
You could learn project management techniques... -- Yes; that would be good. However, without limiting my broader goals, my immediate goal is to learn how to organize and manage my working tree.
... there are academic courses available for this... -- Between time and money constraints, this is probably impractical. I also have a low opinion of classrooms; I study faster on my own unless the instructor is exceptional. I agree that it's a thought.
... you could hire an experienced project manager... -- On the face of it, this is absurd. I'm poor folks. But as you say, the cybersphere is full of starving experts. Maybe I should offer one a hundred bucks to put together a reading list. The question then is, "Who can I trust for good advice?"
... I understand that you want to do things your own way... -- Actually, not. I know I have some goals (which is a good thing) but they're flexible (which is also good). But I'm asking who you trust to tell me how you do it.
This seems to be more about pandering to your quirks than anything else. -- No. This is about finding resources that bin with my leanings. We all have to make some choices before we can make others. I've made a few, subject to change.
Your quirks seem very peculiar/personal... -- Hm. Keep like with like; short identifiers; AvoidMixedCase; stable, boilerplate solutions; adhere to standard practice when possible. Linux, Perl, Git, Module::Build. I adopted these preferences from multiple, well-respected sources. See where I wrote "Please don't say these are silly quirks..."? I meant that. If you feel compelled to argue strongly against any of them specifically, I'll study your comments.
... I use the Eclipse IDE... -- I've experimented with Eclipse/EPIC; I prefer other tools, so far. I may spend more time with Padre. But I'm asking a different question than "Which tools do you like to use?" I want to know what you do with them.
It seems you are looking for perfection... -- I'll settle for a reference to a book you have read and now endorse. If you'd care to offer one.
It just seems to me that you want the community to ratify the approach that you have elected to take... -- Then you seem wrong. I'm looking for your barbecue sauce cookbook. If I've shown you my current recipie, it's to point up the disconnect between what I've got and what I want.
This is a craft, not an art. -- What you imply otherwise is "this is an art, not a technique". I disagree; or rather, I have faith that standard techniques exist, which I can learn. I'm not attempting to create works of art; utilitarian devices will suit.
... try doing what everyone else does... -- Unless I'm completely confused, everyone else does not just tarball up their working tree; and everyone else lists some things in .gitignore; therefore I cannot find out what everyone else does, since neither CPAN tarball nor Git repo completely reflects their working trees.
Use normal folder structures... -- I'm trying to learn, with maximum specificity, what these structures are. Then I can use them.
Broadly, I categorize replies received so far in this thread, as well as those I've gotten over time elsewhere, thus:
Monkey see, monkey do. -- This doesn't work for me because I'm not part of a team, not under an experienced master. What I want to see is what happens in the kitchen, not what's put on the plate.
Muddle through your own way. -- This is what I've been doing. It sucks. I don't even want to eat the results. I'm man enough to admit it.
Listen to me. -- Point to a specific reference, preferably a nice thick book or two (or five). You cannot possibly tell me all I want to learn in three paragraphs. If you wrote the book, that's great. When I buy it, you'll earn some cash money.
The barbecue sauce is esoteric and mystical. You cannot find the recipie, for it does not exist. -- Bullshit. This is an engineering problem. There may be multiple competing approaches but some produce good results and are therefore tasty.
Is this really the best y'all can do?
In reply to Re: Project Structure Revisited
by Xiong
in thread Project Structure Revisited
by Xiong
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |