Not only for the source files but also other related artifacts such as reports. There could be more than one standard covering different aspects but the main point is that it should not be too specific e.g. only for git. Sources preferably from ISO, IEEE, …
Related
Very new to cTAKES and looking through the docs, curious about what exactly the UMLS and SNOMEDCT "vocabularies" are. The user installation docs don't really seem to tell and simply applying for the UMLS license and the language around the UMLS Metathesaurus does not really divulge much more about the structure of the data being accessed. Eg. is it some online API service? Is it some files that come with the cTAKES download that can only be unlocked with a valid UMLS password that is checked against an online DB?
Info on what the UMLS Metathesaurus and SNOMEDCT are can be found here (https://www.nlm.nih.gov/research/umls/knowledge_sources/metathesaurus/index.html) and here (https://www.ncbi.nlm.nih.gov/books/NBK9676/, specifically https://www.ncbi.nlm.nih.gov/books/NBK9684/):
The Metathesaurus is a very large, multi-purpose, and multi-lingual [relational?] vocabulary database that contains information about biomedical and health related concepts, their various names, and the relationships among them. Designed for use by system developers...
...The Metathesaurus contains concepts, concept names, and other attributes from more than 100 terminologies, classifications, and thesauri, some in multiple editions.
While I'm not sure how exactly cTAKES implements its use of the UMLS Metathesaurus (anyone who knows could please enlighten), I assume that it is accessing some API for a relational database based on the UMLS credentials you need to add to the example scripts that come with the cTAKES download (see https://cwiki.apache.org/confluence/display/CTAKES/cTAKES+4.0+User+Install+Guide#cTAKES4.0UserInstallGuide-(Recommended)AddUMLSaccessrights).
...You may select from two relational formats: the Rich Release Format (RRF), introduced in 2004, and the Original Release Format (ORF).
(I think) this is what is used to power the UIMA analysis engines used to process text in cTAKES
UIMA is an architecture in which basic building blocks called Analysis Engines (AEs) are composed in order to analyze a document [...] How Annotators represent and share their results is an important part of the UIMA architecture. To enable composition and reuse, UIMA defines a Common Analysis Structure (CAS) precisely for these purposes. The CAS is an object-based container that manages and stores typed objects having properties and values, https://www.ibm.com/developerworks/data/downloads/uima/#How-does-it-work
I had seen a tool a while ago that would let me define rules for GitHub pull-requests, and could be enforced during CI.
The rules could be for instance:
The commit title should respect a format
The number of files changed cannot be higher than 10
There should be no stray ":focus" in the specs
etc.
I can't remember the name of this tool.
HoundCI by thoughtbot is a pretty popular tool. It is SaaS-based and free to use for open source projects: https://houndci.com/
It supports ruby and javascript.
I found the tool I was looking for: it's called Danger:
What is Danger?
Danger runs after your CI, automating your team's conventions
surrounding code review.
This provides another logical step in your process, through this
Danger can help lint your rote tasks in daily code review.
You can use Danger to codify your teams norms, leaving humans to think
about harder problems.
For example?
You can:
Enforce CHANGELOGs Enforce links to Trello/JIRA in PR/MR bodies
Enforce using descriptive labels Look out for common anti-patterns
Highlight interesting build artifacts Give specific files extra focus
Danger provides the glue to let you build out the rules specific to your team's culture, offering useful metadata and a comprehensive
plugin system to share common issues.
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 :)
Documentation is not the favorite area of a developer but an important area to fulfill if you want to have standards in the organization. We are trying to put together a new Configuratio Mgmt Plan to setup Change Controls, Backups strategies and other fun things, like the process from development, staging to production.
I will like to have your opinions on good examples or probably a good start for CMP process.
If you would like some list of the item in software configuration management plant, this links provide an example: http://www.scmwise.com/software-configuration-management-plan.html
However, please notes that the content of SCM plan is highly dependent on your company standard and the process during software development itself.
I usually refer cmcrossroads.com for such information. The site is not organized well but has lots of info. Another very useful resource is nasa.gov (I know).
Rather than me listing out the index of a CM plan, I would recommend you to check this link out: http://www.nasa.gov/centers/ivv/pdf/170879main_T2401.pdf
Some quick pointers for setting up CM process:
You absolutely need the
management's/corporation's backing.
Without them pushing, no one will
adhere to the process.
SCM is like police/postal service. No one remembers them until something goes wrong. In your case, it is a good sign if no one talks (complains) about your implemented SCM process.
Open source SCM systems are at par with the other kind. Depending on the intensity of your project, you may have to do several POCs to determine which system suits your needs.
This is a vast topic; I would recommend Alexis Leon's book if you are stuck.
Software development related all kind of documents are available as part of Rational Unified Process[RUP]. You can find those at:
Configuration management Plans
RUP templates
RUP templates
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.