How to organize your development environment
For me, this is the following list of directories in the project root:
- src for .java files using package hierarchy
- lib for 3rd party JARs if I don't get them from the repository (e.g. Spring distro)
- for JUnit or TestNG test files
- resources or configuration for .properties, .xml, etc.
- web if it is a web application containing WEB-INF and all its maintainers.
- docs if I have documentation
I love the structure that the Spring people have developed with.
I am using IntelliJ, so I want to have a structure that I need to play well with.
I have a directory / job that stores all of my Subversion working copies.
source to share
It really depends on what tools you use and how you like to organize it.
For example, I've seen people use Eclipse but put each project in one workspace, or use one workspace for each project. The actual storage of projects can also vary. So, I don't think there is an accepted practice.
I think you will need to figure out what works best for you.
source to share
I have a folder called "Work". I have projects in this folder.
The project contains all of my developed software, one directory for each, with a conventional name. Each directory is a complete bazaar repository, contact tags, trunks and branches (a legacy of my old svn style, maybe I'll change soon).
I also develop specific deadlines for projects. Each runtime is loaded and installed via a makefile, which downloads and compiles everything you need (libraries, interpreters and compilers in the worst case, some libraries require a specific version).
Since my work is mostly about little code, I also have archived and legacy subfolders in Project where I put things that I no longer use (the first one) or have been replaced by a better program (outdated). I never throw away old code as it might be useful tomorrow.
For deployment and use, I have a python script that goes into each Project subtitle and downloads the dependencies, compiles everything and packages it as a nutz file (a kind of jar file for the Chestnut Package Manager utility, my product).
Most of the time, professionals use IDEs that do everything for them. I don't like this approach because it often takes longer to use and learn the IDE than what I did. IDEs are implemented with the idea that you have business clients and a potentially large software project involving a team. At this point I am out of this scale, and for me, using a complex IDE, it would be possible to transfer the transatlantic for a good weekend at sea. Completely off the scale for my current needs.
source to share
It depends a lot on the programming language you are using. I am programming in java and the best framework I have seen there is given by maven .
You don't have to mess around with dozens of jar files because of maven's large dependency management. You can use existing plugins to accomplish almost every goal you can imagine. And you can structure your projects into small sub-projects for optimal reuse.
source to share
I have everything in source control repositories (nb: a very restful set of files that are there and for testing backups). On my dev machines, I have a Projects folder for checking current / recent work, and a Projects / Archives folder for older checks that I am not currently working on. When I need third party libraries for a project, they go into the third_party folder inside each project. They are tracked by git submodules which give me exact versions of the software that are known to work with this project, but are also easily updated across projects, hack if some library doesn't do what I need, etc. ... The idea is that each project should be autonomous and portable between machines, as far as is reasonable for reliability, etc.
source to share