There are two popular naming conventions:
vc90/win64/debug/foo.dll
foo-vc90-win64-debug.dll
Please discuss the problems/benefits associated with either approach.
I am also wondering if it is possible to expose meta-data (i.e. compiler, platform, build-type) in approach #1 in an easy to use, cross-platform manner.
#2 is good for distribution, where several variation will be packaged in the same folder/zip file together. However, you probably don't want all that information in the file name itself, as it make it difficult to vary those via parameters to your makefile/csproj/nant script etc. It would be easier to have several files called "foo" in different folders (where you can decide the folder structure)
For .NET assemblies, you can store this information in the assembly itself:
http://www.codinghorror.com/blog/archives/000142.html
I'm not familiar enough with other assembly types to know what they provide.
Related
i am making an object-oriented app in coldfusion, and so i have really broken down the code. so, i have really long namespaces for my components; for example:
folder1.folder2.plugin1.datatypes.Object
i seem to be repeating a lot of stuff, but at the same time, some of these things are acting like "modules". what i mean by this is that "folder2" in the example really contains, for lack of a better term, "stand-alone" components/applications (think of them like plugins). so, aside from them calling other plugins' resources, they act on their own. but, due to the folder structure, i still have to refer to them all as folder1.folder2.... and so on.
so, let us assume that the "folder1.folder2." could change on a whim. (this will not happen, but since "plugin1" would define a stand-alone component, it does not care what "folder1" or "folder2" contains, if they even exist).
when i am writing code within the plugin, is there anyway i can shorten the namespace string; is there such a thing as "relative" namespaceing, just like using relative href links?
such a thing would save me a lot of time, but would also help ensure these things are more stand-alone as they would not be tied to their encapsulating folder structure...
You could use ColdFusion mappings, specifically per-application mappings in Application.cfc.
You do this in Application.cfc
<cfset this.mappings["/com"] = expandPath("folder1/folder2/plugin1") />
The you could reference components by doing com.datatypes.object.
Cannot recall when per-app mappings came about, but its been there for a few releases.
Sounds like you may want to consider dependency injection such as WireBox. This would allow you to have a single configuration file with the full paths and allow you to use an alias to obtain your models. In fact, you can even have wire box scan locations so you don't have to list every object you create.
WireBox was extracted from the amazing ColdBox framework. It is available independently of the ColdBox framework and should be somewhat simple to introduce into your application.
There is a helpful Google Group for ColdOx (and related boxes), ColdBox connection meetings that are recorded and other types of training available for WireBox.
I can not imagine building sophisticated OO without dependency injection. Well worth the effort to learn and implement.
At which point do you decide that some of your subroutines and common code should be placed in a class library or DLL? In one of my applications, I would like to share some of my common code between different projects (as we all know, it's a programming sin to duplicate code).
The vast majority of my code is all within a single project. I also have one small utility that's partitioned from the main executable that runs with elevated permissions for a sole purpose. The two items have, at most, three subroutines in common. Should these common subroutines be placed and called from a class library? How do you decide when to do this? When you have at least one shared subroutine? Twenty-plus lines of code?
I don't believe that this should be language specific or framework dependent, but if so, I'm using the .NET framework.
There's more ways to share code between applications than with a DLL. From what it sounds like, you're not talking about a lot of code, so it sounds like you don't need to worry about it too much.
In general, I use the following rule of thumb:
For trivial code duplication (a couple simple 1-2 line functions, that are easy to understand and debug) I'll just copy and paste the code.
For more complicated functions (a small library of stand-alone helper functions, contained in a file or two, which require a modest level of maintenance and debugging) I'll simply include the file in both projects (either by linking, or defining a subrepository, or something like that).
For more extensive code sharing (a group of interrelated classes, or a database communication layer, which is useful for multiple projects) I'll refactor them out into a standalone library, and package and distribute them using whatever's appropriate for whatever I'm programming in.
Because the complexity of managing your code increases by an order of magnitude for each step (when you're packaging DLLs for multiple projects you now need to think about versioning issues) you only want to move to the next level when you need to. It doesn't sound like you're feeling the pain of handling your common code yet, and if that's the case there's no real need.
If code is shared between multiple applications, then it has to reside in a DLL or class library.
For a larger application you might also want to break different subsystems of the application into separate libraries. That way each project can focus on one particular task. This simplifies the structure of your application and makes it easier to find any one piece of code. For example, you might have a GUI application with different DLL's (.NET projects) for:
Working with a specific Network protocol
Accessing common code, for example utility classes
Access to legacy code (via PInvoke)
etc...
I would like to ask you for your opinion on the best practices of managing big numbers of complex (for example xml, .properties, custom formats etc) configuration files as nowadays every more complex project consist of way to many to count.
How not to get lost in such a mess? How to reuse those in best ways? Any good tool that can help (maybe some Eclipse based)?
Obviously, the most fundamental thing to do is to put those configuration files into source control, as they really are a kind of source code.
But the real challenge with configuration management is deciding how many files to have and what to put where so that you can reuse common configurations. Those are design decisions and very project- and environment-specific, and no tool can make them for you.
A common approach is to have a master config file that contains default values, and environment-specific files that contain only those config values that are different for their environment, and which overwrite the defaults. This happens as part of an automated build process (which you really, really should have).
I'm not sure if this would be applicable to your situation, but I'd try and store them all in a database in a normalised fashion. maybe you need a could write some import tools that grabs the info from the files and adds them to the db.
Alternativly reading this, or this might help you.
I saw some questions raised about the folder structure of source codes, but I never see the question about folder structure of project documentation. I googled it and still do not see many articles talk about.
Here is one http://www.projectperfect.com.au/downloads/Info/info_project_folder_structure.pdf
To quote some of its words:
"There are two broad approaches:
Organize by phase so that each top
directory is a phase. For example,
you might have directories for
Feasibility, Business Analysis,
Design etc. or whatever your phases
are called.
Organize by function so that the top
directory level are functions. For
example, Risks, Requirements, Scope,
Change Control, Development.
Most times a mix of both are used..."
So any thought about it? I believe this is also an important issue!
IMHO depending on your document management system the choice of structure for your documents may not be an issue. When looking at the problems project related documents are trying to solve you typically come to the conclusion that documents are about communication.
Different documents attempt to communicate different things (or contexts); test plans discuss how testing should/has been executed, requirements specifications discuss how the business rules should be applied, architecture documents discuss the technical components and so forth. Each of these documents might have the need for its own unique structure. For example the structure you choose for your test plans may be vastly different from the structure you need for your architecture documents.
When keeping the communication issue and the document context in mind I generally come back to these 2 key aspects.
Searchability – What is the easiest way to find the document I am looking for?
Versioning – How do I know that the document I am looking for is the most recent one?
I feel searchability is the most important thing to remember because different people call the same document by different names. For example some people call Business Requirements documents Functional Specifications. Some people call Functional Specifications use case documents. As you cannot always govern the naming convention of documents I feel finding the right document to be far more important than the folder or place in which it is stored.
So to answer your question I would simply answer by saying it doesn’t really matter which structure you use, just that you should use some form of document management system (SharePoint, Documentum, Trim, etc). The benefits are simply too great to work without one :)
I'm working on several distinct but related projects in different programming languages. Some of these projects need to parse filenames written by other projects, and expect a certain filename pattern.
This pattern is now hardcoded in several places and in several languages, making it a maintenance bomb. It is fairly easy to define this pattern exactly once in a given project, but what are the techniques for defining it once and for all for all projects and for all languages in use?
Creating a Domain Specific Language, then compile that into the code for each of the target languages that you are using would be the best solution (and most elegant).
Its not difficult to make a DSL - wither embed it in something (like inside Ruby since its the 'in' thing right now, or another language like LISP/Haskell...), or create a grammar from scratch (use Antlr?). It seems like the project is large, then this path is worth your while.
I'd store the pattern in a simple text file and, depending on a particular project:
Embed it in the source at build time (preprocessing)
If the above is not an option, treat it as a config file read at runtime
Edit: I assume the pattern is something no more complicated than a regex, otherwise I'd go with the DSL solution from another answer.
You could use a common script, process or web service for generating the file names (depending on your set-up).
I don't know which languages you are speaking about but most of languages can use external dynamic libraries dlls/shared objects and export common functionality from this library.
For example you implement function get file name in simple c lib and use acrros rest of languages.
Another option will be to create common code dynamically as part of the build process for each language this should not be to complex.
I will suggest using dynamic link approach if feasible (you did not give enough information to determine this),since maintaining this solution will be much easier then maintaining code generation for different languages.
Put the pattern in a database - the easiest and comfortable way could be using XML database. This database will be accessible by all the projects and they will read the pattern from there