Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
the project I am working on ship a package that contains API for different languages: Java, Python, C#, and others. All these APIs shared mostly the same documentation. The documentation should be available in PDF and HTML separately on our website. The user usually download/browse the one it is interested in.
Currently we use sdocml, but we are not that satisfied and so we want to move to a more up to date tool and we are considering Sphinx.
Looking at the Sphinx documentation I cannot clearly figure out how:
1- say to generate the docs for a certain API (for instance the Java one)
2- does autodoc works for any domain?
3- is there a c# extension?
Any help is most welcome!
The best way to combine different languages in one Sphinx project is to write docs without autodoc or other means of automatic generation. For the most part they are available only for Python and even if some extension out there does allow other languages, you will be buried under different workflows before you even notice.
Salvage your docs from the code and write them in concise manner in a separate docs folder of your project or even separate repository. You could use the generic Sphinx directories like class or method with no attachment to the code and for virtually any major programming language. I for myself did a project like that, where I needed to combine C, C++ and Python code in one API and it was done manually.
If you create this kind of detached project, the maintenance should be much of an issue. It's not much harder, than autodoc workflow. What for PDF and HTML - any Sphinx project allows that. See their docs for details on different builders like latexpdf or html.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
Can anyone give advice, or point to any guides, on how to manage a community of open source software developers in writing api documentation?
A typical, unmanaged, starting point for most projects is to have a project wiki where anyone can freely create pages, add content to existing pages, edit existing content etc. The problem is that, despite people's best intentions, the wiki can easily end up being a disorganised, poorly written, incomplete, written in disparate voices etc etc.
So, what to do to improve the quality of the documentation?
I suspect a key ingredient is clear editorial/style guidelines, something similar to http://en.wikipedia.org/wiki/Wikipedia:Encyclopedic_style#Information_style_and_tone. Can anyone point to an example of such a guide tailored specifically to software apis?
Are there any other practices that people have found useful? E.g. form a core team of editors and accept that most documentation that gets added by the community will most likely need to be 'strongly edited'?
The short answer, that the solution is social/human and not technical. The way to get good documentation for any project is to have someone with time, in charge of doing high level organization for the documentation, and then being involved in the development and user communities to ensure that the documentation remains up to date and continues to address the problems and confusions that users typically have.
Community projects have accepted that you need point people (i.e. "managers," for aspects of the project like "translation," and "release," and for various components. The same thing needs to happen for documentation.
As for tools, Sphinx is really great though it's not "wiki like," exactly you can use whatever version control system your project is comfortable with to store documentation and configure your web server to rebuild the documentation following commits/updates/pushes. Which has always worked just fine for any project I've worked on/with.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 5 years ago.
Improve this question
I use a lot of illustrations, diagrams and equations to document C++ and python codes, and a way to do this is to inline them with doxygen. The problem is that, when coding, they are not directly available in the code (unless I use ascii-art for this purpose).
Is there an automatic, quick and fast way to, while coding, view the generated documentation? E.g., I could have a separate Eclipse tab with the rendered documented code (HTML), while coding in another tab... and the documentation rendering tab would be updating automatically as I change the code and the documentation.
Is this possible? Is there a tool, plug-in for Eclipse or add-on for Visual Studio enabling this?
Frankly, I use a second monitor (or second computer) to view such documentation just to keep them out of the way - I want to see them alongside my Visual Studio screen not taking up space that could be occupied by code.
I publish the generated Doxygen documentation to an internal web server so if you have an HTML viewer plugin you could just point it to that. (I usually have a browser open alongside).
You could setup your Doxygen project to be generating directly into the web server directory so there's no copying time to get it renewed.
One tip, if you have a large code base and Doxygen takes an annoyingly long time is to have a special setup file just pointing at the code you're working on, to quickly regenerate the relevant couple of pages. You could have a python script observing the directory and re-running Doxygen if files change.
Try my LP tool - http://code.google.com/p/nano-lp - it supports OpenOffice/LibreOffice, so you can write LP programs in WYSIWYG manner. By the way, if you decide to use markup language instead of OpenOffice, NanoLP supports several of them.
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 5 years ago.
Improve this question
I'm looking for a nice way to generate documentation for a REST API. It doesn't need to actually connect with the code or anything, but it'd be awesome to be able to write the documentation as text files, point the tool at it, and generate some docs from it.
Anyone out there have any ideas? I know I'm being a bit vague, but, to be honest, I'm not quite sure what I'm looking for here--mainly an easy way to manage documentation.
According to Roy:
"A REST API should spend almost all of its descriptive
effort in defining the media type(s) used for representing
resources and driving application state, or in defining
extended relation names and/or hypertext-enabled mark-up
for existing standard media types."
Self-descriptiveness is one of the benefits of REST.
While not REST, I used Sphinx to document an XML-RPC API that consisted of an API reference and a tutorial. Sphinx adds some handy directives to ReStructuredText to get pretty much what you asked for: a collection of ReStructuredText formatted-text files that Sphinx turns into HTML and PDFs, complete with an index and table of contents. Sphinx is easy to use and well-documented; I don't think it would be an exaggeration to say you could get started with it in about ten minutes.
Some RESTful systems are actually able to write their own API. Have a look at RESTx, which does just that: You write your components and then create new web services by sending parameters for those components to the server (either as JSON or via a web form). You then get a URI back for those parameters. Accessing it calls the component with the parameters and you retrieve the results.
At any rate, the components as well as the created RESTful web services get an automatically generated documentation, which is browseable and can be retrieved either in HTML or JSON format.
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 5 years ago.
Improve this question
I work for a insurance company. We have our own development department made-up of almost 150 people plus some providers (outsourcing and custom made apps pretty much). In our company my team have made what we call non-functional logic libraries. That is, software libraries to handle things that are horizontal to all the development teams in our department, e.g. Security, Webservices, Logging, Messaging and so on. Most or these tools are either made from scratch or adaptation of a de-facto standard. For example our logger is an appender based on Log4J that also saves the logging messages into a DB. We also define what libraries to use in the application, for example which framework for webservices to use. We use pretty much JavaEE and Oracle AS in all our organization (with some Websphere Application servers).
Much of these projects have their architecture documented (use cases, UML diagrams, etc) and generally the generated documentation are available.
Now what we have seen is that for users sometimes is difficult to use the the libraries we provide and the are constantly asking question or they simply don't use them.
So we are planning to generate a more friendly documentation for them, so my question is:
What are the best practices or the checklist that software documentation should have?
Something comes to my mind:
API Reference guide
Quick start Tutorial
API Generated Documentation.
Must be searchable
Web Access
What else should it have? Also, based in your experience what is the best way to maintain (keep it up-to-date) and publish this type of documentation?
Keep your documentation in version control too.
Make sure on every page it has a version number so you know where your user has been reading from.
Get a CI server going and push documentation to a LIVE documentation site upon updates.
Do documentation reviews like you would code reviews.
Dog-food it :)
Kindness,
Dan
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 5 years ago.
Improve this question
I have inherited over 600 files of ColdFusion source code running a internal web site for my company. One of my tasks is to "document" it. The code base represents about 5 years of development and there is no technical specification of what it does.
The developers have maintained a change log of each file and there is a consistent header.
My thought is that I can build a dependency map of the various modules and referenced stored procedures to facilitate this documentation by scanning the source files. I have used Doxygen in the past for c++ source code and am wondering if a tool like this exists for ColdFusion.
One output I am investigating is the ability to create a xmind file as means of visualizing the cross dependencies in module inter-relationships.
Thanks in advance,
Chris
The ColdFusion server has built in introspection that outputs javadoc like documentation for any CFC class.
See: http://YourColdfusionServer/CFIDE/componentutils/componentdoc.cfm
However, it requires an RDS login/password for your server. For delivery to third parties, I set up a recursive script that does a cfhttp fetch against the docs for each cfc file, and then compiles the pages to PDF with cfdocument.
You could start with ColdDoc
Also, heres a UML 2 CFC generator.
I guess what you really need is something to reverse engineer the coldfusion code into uml class diagrams. I don't know of anything off the top of my head.
MagicDraw, Objecteering don't seem to do it yet.
After trying to find an answer to this question myself I ended up writing this solution:
ColdDuck
Maybe it is too late for you now but I am just spreading the word.
Murray
Sounds to me like creating your own Xmind or XMI file is the way to go. The XMI file may be more portable between tools, but the last time I looked at doing that the XMI file formats were a bit daunting for the time I had available to work on the solution. If the formatting of the headers consistent is enough to read with ReFind or Find I'd build a script that uses cfdirectory and cffile to walk the code tree and output the file(s).