I am working on a project which spellchecks developer documented, e.g Readme files. The project uses Hunspell for spellchecking, but developer documents contain a lot of jargon which Hunspell thinks is misspelled.
My workaround so far has been to build my own custom dictionary to use alongside an English dictionary which contains jargon words, e.g git, repo, xml, url
I have not been able to find a decent word list of developer terms, does such a thing exist?
My question is this, is there an easier way?
Related
We are looking to store our Software company's all documents which can be easily modified, searched, shared withing Teams.
It is like Sharepoint but need more sophisticated tool which undertand various document formats
Like Swagger , Code Files, Excel, and very well sturcutre to orgainize and link documents.
We can to create our Architecture and Solution Repository
ok, then you need:
1- a store
2- version control utility
3- a tool too develop togaf specific stuff (views, viewpoints, stackholder definitions, ABBs, SBBs, architecture diagrams, container documents that refers to these diagrams such as architecture definition and architecture contract docs )
4- a tool to understand various document formats to track the changes internally (including word documents and excel sheets)
let me start from bottom up,
4-I don't know any tool that is able to understand complex format like docx, even microsoft tfs deals with word files as a binary file, thus it can't track the changes done inside a document, I think you will need to compromise this point and rely more on a well structured process of providing sufficient and precise comments by whoever commits to the repository + well utilizing components in point 3
3- Archi (free) - Sparx / visual paradigm (commercial) (I have a very small experience with it but it seems to be sufficient)
2- any source control tool (git / svn / tfs / mercural) .. and if you use Archi, it's eclipse based and eclipse has plugins to most of source control tools
1- according to point 2, the repository will be defined, in case of git for example it will be a Git repository
but any ways, you will need to define a process and guidelines inside your organization for managing the architectures then the tools will just support.
Though not perfect, hope it helps !
Though a bit late, let me try to answer from my experience. Enterprise Architecture Platforms / Tool should fit your expectations with many more features that you need for architecting solutions other than the primary document management, collaborations and content management.
I suggest you to look at Orbus IServer as it is purely document based. It accepts all Microsoft format files like visio, excel, docx, powerpoint, sharepoint, power bi. It also accepts ERWIN files
Here is the link which speaks about its integration.
I'm part of team working on SDK that is exposed with several programming languages - currently ObjC, C#, ActionScript, Java (Android) and later we'll have even more languages.
We want to have documentation which is made up of two parts:
Human readable documentation
API Reference
There are links between the two parts: from human readable docs we have links to specific classes or methods and from the API reference we may link to a document that explain the context in which the class or method is used.
We are currently use a combination of sphinx for human readable documentation and language specific tools for API such as doxygen or asdoc
I saw in LeapMotion they were able to generate a complete documentation for multiple programming-language (not human language) with cross links between programming-languages.
The Question
Does someone know how to accomplish such documentation system in a way we'll not have to duplicate each change in human readable docs to every language and have cross links between the languages?
I put together the Leap Motion documentation. I use Sphinx to create the package of docs and Breathe, a Sphinx plug-in, to basically import XML files generated by Doxygen into the Sphinx project for the doxygenated API references (C++, C#, Java, and Objective-C). For links from the so-called "human-readable" pages to the API references, I generate RST substitutions from the .tag files which Doxygen will generate for you. Links from the API reference to the "human-readable" pages are normal, relative hyperlinks (which I should add more of).
I use the conditional content features of Sphinx to generate a separate set of docs (both "human-readable" and API) for each programming language. Thus these articles can be customized for each programming language where needed and have the correct code examples for the current language. Because each doc set has the same structure, it isn't hard to switch from one language to another.
I did add some custom JavaScript to the page templates to help switch between languages.
tl;dr: Sphinx, Breathe, Doxygen and a small amount of custom JavaScript.
If you would like to discuss this further, you can post a question to our (Leap Motion) developer forum. I'll see it (Stackoverflow isn't the proper place for an ongoing discussion).
Hi Ido Ran,
Tools which you've specified are best in industry for documentation purpose,I am afraid there is no such tool yet which could provide both human and as well as API reference.Out of all my personal best is doxygen which is slighly of multi-use (human and API)..Hope this helps.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
The task
We'd like to maintain some developer's documentation for our .NET projects with the following criteria:
"Documents", ideally written in Markdown for providing information that's not closely related to a piece of code (like overview, FAQ).
Standard inline comments for code and API documentation. We do thus in form of standard inline (XML) comments on the classes/interfaces (primarily for IntelliSense support, secondarily for being able to generate an API reference) and would like to continue to do like that.
The documentation is contained in what it documents; e.g. if it's an overview of a solution then in the solution, if it's for a project then among the project's files, version controlled in the same way as the code (this is so the docs are close to what they document, so they are less prone for going out of date, and also this was docs are always "at hand").
Ability to auto-generate (from the CI server) a readable, compiled documentation for a whole project, including "documents" and inline comments for APIs.
An example
We've a project that's a component usable within a 3rd party system. For this project we have the following type of documentation:
Overview (what the project does, what are the aims)
Installation instructions
API documentation
Version history
We'd like to enable our developers and other developers to
- read this documentation from the project's source package and
- from a website.
Solutions we've looked at
Using a wiki (we tried Confluence): this is good for "document"-type of documentation (like overview or installation notes), but it lives independently from the project itself. It's another system to maintain and because it's not before one's eyes when doing development it can quickly go out of date. Also it's one more task to somehow integrate auto-generated API documentation into it.
Using Markdown files and storing them along the code: this is simple and documentation is always at hand and close to what it documents; however we somehow need to generate a publishable web package from these files and the source files' inline documentation.
So far doxygen looks like the solution capable of providing all these. Do you agree?
See "How to include custom files in doxygen".
Broadly speaking this is exactly what I am currently doing, and I'm using Doxygen.
However, I'm afraid I know nothing about .NET. The project I'm working on is a Java package, but includes API documentation extracted from the source, user guides, release records and things like deprecations.
The only thing out of our scope and in yours is Installation Guide, but that's really only because the developer only gets to read it after installation.
We have Jenkins CI building the document on every change.
The 'descriptive' text is all written in Markdown which Doxygen handles reasonably well.
Downsides: If you are familiar with the way Doxygen handles grouping of text for source code you may be confused that these commands don't work to group the blocks of text in Markdown. There are a few other specific oddities but you'll probably find most of them if you scan my own questions on the subject (here, here and here)
Upsides: (Things we've found useful that you've not mentioned)
We can also parse the 'doxygen' markup in the Java API to create a javadoc that IDE's such as Eclipse can use. This does mean we have to limit ourselves to javadoc-style command in the API docs but that's not a big limit.
We've included, under doxygen 'build switch', a manual for your developers on how to write the documentation for the manual (OK, this is slightly recursive!). This provides the recommended command subset to use, and whether (according to taste) you want people to use doxygen #subsection or Markdown ## for headings etc.
Hope that helps.
I'd suggest you try it; trialling a sample of each type of document section you need, to see if it will do the whole set of functions you need. Nothing more annoying documenting 90% then finding it won't do the last 10%.
I've seen this question in various guises around the place, but as yet haven't found a suitable answer. If this is a duplicate, appologies (I'd be surprised if it wasn't a duplicate!)
Basically, I have a project which is using (mostly) shell code and sql. I want to make sure all the files have a similar setup, and that I document things consistently. To this end, I want to have template files / skeleton code within Eclipse.
It seems easy enough with Java, but not other file types. I have checked out ShellEd and it didn't appear to have this feature (correct me if I'm wrong).
It would be great to be able to add this as a new file type, such that I can say File -> New -> sh/sql and have the correct basic template with the right header etc.
Also, if possible I would like to be able to, one click, add a function prototype with the correct documentation to my files...
I thought this would be easy enough, but a few days of Googling and messing about, it seems I need to write a plugin of my own... but I can't beleive that it's not possible, more likely my Google skills aren't up to scratch...
any help?
cheers
Rob
P.S I'm normally a Vi (not Vim) user, but have had Eclipse forced upon me!
For SQL the Data Tools Platform Extender SDK (DTP) Eclipse project contains a SQL editor with templates (under Database Development in Install New Software).
What are the software/ Wiki you use to write and share your specs about the developers, testers and management?
Do you use Wiki system, and if so, what Wiki software you use?
Or do you use Sharepoint to manage and version the specs? One problem with SharePoint 2003 as specs platform is that it's very hard to collaborate among different people.
For backward compatibility sake, I would also like to have the platform able to import Microsoft Word seamlessly. And it would certainly help if the interface is similar to Microsoft Word.
Any idea?
I've used Confluence at a number of places, it's a pretty powerful wiki and very good for creating specifications that can be shared amongst various parties. See:
http://www.atlassian.com/software/confluence/
There's some more information here on the advantages of using Confluence:
https://stackoverflow.com/questions/170352/confluence-experiences
EDIT: I've updated this to deal with the Microsoft Word import feature you mentioned. Confluence supports this through the Office Connector here:
http://www.atlassian.com/software/confluence/plugins/office-connector.jsp
There's also a Sharepoint connector:
http://www.atlassian.com/software/confluence/plugins/sharepoint-connector.jsp
plus a whole bunch of plugins:
http://www.atlassian.com/software/confluence/plugins/sharepoint-connector.jsp
Some of these are user contributed also. I can't recommend Confluence enough as a commercial wiki.
I've also used JSPWiki, which is open source. it's ok but not as good as confluence, see:
http://www.jspwiki.org/
You could try Google docs - I have successfully used this in the past. It supports import / export to MS Word, and it has great support for multiple user - see http://www.brighthub.com/internet/google/articles/8236.aspx.
It supports versioning, allows you to chat with other people who are currently working on the document, and shows you a list of all the changes others have made to the document (without needing to close / reopen the document).
If you want corporate support, Google also provides that - see Google Apps for business.
We use SharePoint -- it's not ideal, but it does a decent job. If I were you, I would seriously look at getting off SharePoint 2003 and on to MOSS (SharePoint 2007). It's not perfect, but it's substantially better. Here's a little bit on using MOSS as a wiki. I think in general wiki's are a good tool for getting people up to speed on your system. We used to pass around "getting started documents" and now we have all that type of stuff in our developer portal.
Per John's comment, I looked up this feature comparison. I have to go back and look at what features I'm using that are not in WSS -- I might be paying for licenses I don't need! :)
We use email. I know it isn't elaborate, but it is easy to use. Everyone has it installed and there are no licensing issues. All spec changes are sent to an super set email distro indicating the updates and the location on the network share where the spec can be found.
We use Alfresco, in its Community version, from both its Share and Explorer web interfaces.
Quite useful, with a document library, wiki, forum and calendar.
We curently host about 1.8 Go consisting mainly in docs, versionned and sometimes automatically converted to PDF (by creating an automatic content rule).
FTP, WebDav and network share are also used to access to the same repository.
You could take a look at Microsoft Groove - the collaboration software that Microsoft bought a few years back.
It's bundled free with premium versions of Microsoft Office.
You can customize the workspace with discussion boards and can fairly seamlessly store collaboratively-edited Office documents.
We use MediaWiki for dos & specs. Wiki definitely wins anything like Microsoft Word or SharePoint - it allows you to develop a documentation in "first refer, then describe" = "divide and rule" way. Perfect for developers - they used to think the same way. The process of developing a documentation is almost ideal: you start from TOC and drill down until you write the document for every link you put earlier.
MediaWiki is quite customizable - there are lots of extensions there. The most necessary ones are:
Source code highlighter - CSO_Source
Our own templates integrating wiki with class reference.
Others are InterWiki, FileProtocolLinks, YouTube (we use customized version of it to display HD video), ReCaptcha, SpecialDeleteOldRevisions, Maintenance.
Some integration examples are here.
And we use Google issue tracker to track the issues. Its main advantages:
Imput usability: the process of adding\changing the issue is really convenient there. Earlier we tried Track Studio - the same actions require 2-3 times more time there, so it died fast simply because most of us hated to use it.
Customizable grids. See the examples. Really helpful.
Atom\RSS support. So everyone knows what's going on.
There is a Gurtle tool integrating it with TortoiseSVN. Really helpful.
Its main disadvantage is that it can't be closed from the public access. This makes it simply unusable in many cases.
If you want a UI similar to Word, why not use Word with SharePoint 2007? You're on 2003 so the experience is there. Upgrade to SharePoint 2007 and you can have the collaboration, Word features, document sharing, and so on.
This is the kind of thing Microsoft wants people to use Office for, so there's a ton of doco out there about how to configure your SharePoint and Office environment to support collaboration.
There is something that Google do in this direction and it looks really cool: wave.google.com. It would be a great step in collaboration and worth to wait it.
Here we use Google Docs it makes the documents available to everyone write or read only, public or private among people that have or not Google accounts, it also can import Word docs, not to mention that it runs directly into the browser so it has high availability with zero cost and zero setup, also its computer/OS agnostic, we have a nice experience with it.
Also perhaps you should take a look at Basecamp or Backpack at 37Signals, any of then might also fit your bill.
We use DocBook for all of our specifications (and other customer-facing documentation). DocBook is an XML format that lets you easily generate documents in just about any format, including PDF, which is how we distribute things to clients to get them signed off. We can divide a document into files (by section) and commit everything to our source control system (Subversion). Because it is all XML (i.e. text-based), Subversion's automatic merging and conflict resolution works great if two people work on the same file. We have a set of stylesheets that all of our documents use, so all documents share the exact same style/format, with no extra work on our part.
And if you don't like editing XML files directly, there are GUI front-ends that provide a reasonably WYSIWYG-like experience. I believe that most people in my office use XMLMind. Still, we happen to all be technical people so if we had to write XML directly it wouldn't be an issue.
As a sidenote, we also put out release notes. We have some XSLT that lets us write documents like this:
<bugs>
<bug id="1234" component="web">JavaScript error when clicking the Kick Me button</bug>
</bugs>
We then have a script that runs through our Subversion repository doing an svn log from the previous release tag to the current release tag, and some Bugzilla integration to automatically generate release notes on-the-fly.
(also, for most internal-only documentation, we use MediaWiki, which is also a great way to collaborate.)
We use OnTime. It was originally only used for defect tracking, but we've started using it to track features as well. These can be used to document the feature as it evolves during development. Features can be grouped together into sprints or releases, and time can be tracked against each feature. If you are using SCRUM, you can also plot burn-down charts for each sprint. It also has wiki functionality.