Is there any way to obtain, or has someone already obtained and compiled documentation from MS Technet Library for offline use?
I know of the Visual Studio Help Downloader at codeplex https://vshd.codeplex.com/ and I am looking for something similar for the Technet Library.
The Library itself has an option to select articles for export however, it is very limited in number of pages to add per click. This means you have to drill down on every subject and add it to your selection. Not very usable, besides the examples state you should be able to download as pdf or html, but I only get the html option, which is annoyingly impractical.
Ideally I would like to have the complete offline documentation for a single top-level subject (e.g. "Scripting with Windows PowerShell" at https://technet.microsoft.com/en-us/library/bb978526.aspx). If possible, including an index/TOC.
I know of the built-in Get-Help, the books available etc. but the Technet Library has more detailed information available which I'm after. Any known method of downloading this in bulk would be greatly appreciated.
All my google search results seem to either point to the built in export funcion, or people reminiscing about the old offline Technet subscription.
Ok, its not great. But its better than the above... I know this is old. But I was looking for this. This is the best I found. So Ill leave my breadcrumbs for the next fool to stumble down this road. If someone else finds better, hopefully theyll continue to pass it on.
On Github, you can download the entire Doc repo as a zip. Read it with microsoft code and a markdown extension.
Ideally, Id like to see this as a CHM (rather than a PDF).
https://github.com/PowerShell/PowerShell-Docs
I was surprised to find that this is well documented, and actually is a thing:
Taking TechNet Offline
When you start the process, it'll give you some instructions, and once you click "Start," you'll be shown the hierarchy of the entirety of that root page you linked on the left. Note the instructions in orange at the top.
I didn't go much further then this, but let us know if this worked in full, and as you expected it to. Nice feature there! I learned something myself today.
I have had mixed success with HTTrack You can give it a site a page and it will go through all links and resources recursively, saving them locally.
It requires some tuning and playing around with to get right, There might even be a newer better equivalent these days.
Related
I'm about to submit this project but I want to make sure the Github page looks good before I do. For some reason, not all the languages are showing up and I don't know why. I've tried to find ways to edit this under settings but I've yet to find anything.
As you see in the images below, on the homepage it says the Repo is 100% Jupyter notebooks, but if you click on "languages" you'll see that there are python and csv files as well that seem to be unaccounted for.
If anyone knows how I can change this please let me know. It's not very important but I think it'd look much nicer if the breakdown of languages was more accurate. Thank you!
GitHub uses Linguist to figure out which languages are part of your project. It has a languages.yml file to defined the multitude of languages to look for. Some are markup languages (like jupyter notebook), some programming languages, etc.
That percentage you see is calculated based on the bytes of code for each language. The more you have of one type, the higher the percentage.
Note, however, that this library excludes all files that it determines to be binary data, vendor code, generated code, documentation, or defined as data (in your case csv) or prose (think markdown), whilst taking into account any overrides.
IF your python code is small enough, even in 2 files, it won't get show up. Just write more python if you want it to show up.
The second screenshot provided is when you click on the languages and it's purpose is exactly what you are looking for - to give better details on the current project and what it comprises of in detail. This language bar is just an overview. It need not be 100% accurate.
FIY - It also matters which is your main branch, since it takes that into account.
Conclusion - don't worry about it. Whoever needs to see it, will see what your project has in terms of contents.
I have not used either of them till yet. I looked at their websites and found their brief descriptions:
Github Gist:
Instantly share code, notes, and snippets.
Pastebin:
Pastebin is a website where you can store any text online for easy sharing. The website is mainly used by programmers to store pieces of sources code or configuration information, but anyone is more than welcome to paste any type of text. The idea behind the site is to make it more convenient for people to share large amounts of text online.
Apart from the explicit mentioning of "anyone is welcome to paste any type of text" in Pastebin's description, I see no difference in what they are used for.
I'd appreciate if someone could point me the differences between them.
Gists are way more 'advanced', since Pastebin is very simple and user-friendly.
At very least, gists are used to be shared mostly with coworkers, while pastebin is heavily being used for wide-usage or for private usage.
https://help.github.com/articles/forking-and-cloning-gists/
I have been looking for some time now, and I decided to try some crowd sourcing.
I have searched (Googled) the answer and looked through Stack Overflow for some time now, and I cannot find a proper and relatively easy way of created DOCX documents via Perl.
I want to create a DOC file, and since DOCX is XML based, I was guessing that would be an easier way to achieve this.
I located a RTF::Writer module but its very limited in its capabilities.
There are more than one such library for PHP, and other languages, but I cannot use that, unfortunately.
I am not running on a Windows environment so I cannot use anything that would integrate with Office, in addition I don't want to start bundling Office with my product.
I am open to suggestions, but please provide sensible ones :) i.e. no, you are scr*wed DOCX is impossible.
Here is what I tried:
1) Take an existing DOCX, and modify the XML directly, all I achieved via this is caused Word to crash :) apparently Word is very sensitive on its attribute order
2) Googled for answers and I found some, like Win32::Word::Writer which only works on Windows and requires OLE and Office
3) Found a lot of posts from 2010, that say its impossible, well almost 4 years have passed, probably something is out there that can do it
4) Looked for commercial solutions, couldn't find one, I found FOP which is able to create RTF, which is pretty close, but it lacks a lot of the styling I would like to use
5) A lot of things (code and modules) that allow extracting data from DOCX, but nothing that can create one, weird
6) Found abandoned code like OpenOffice::OODoc which stopped being written in 2010, and of course requires OpenOffice to be installed, and potentially also requires a non-headless (i.e. requires a GUI system)
Thanks guys for any answers :}
One cheat that I've used in the past is to output HTML with a ".doc" file name.
This gives you less fine-grained control over the document formatting, but may be sufficient for your use case.
The closest I've ever managed is to generate an OpenOffice document and then use that to export as .docx (in headless mode).
You need some fonts installed, but no GUI for this. I use OpenOffice::OODoc, and it's enough to let me open up an existing document and add text/pictures.
The OpenOffice (LibreOffice) export process is not 100% reliable, but I've never been able to get a simple, repeatable test case to reproduce it - just hangs occasionally. I add a timer to kill the process and let it retry.
Not a perfect situation, I'm afraid and I hope someone has a better solution.
It seems a lot to ask, but I'm looking for a cloud-based solution to managing code snippets. I am looking for:
Tags
User accounts (I want to be able to see all of my snippets on a single page)
syntax highlighting
versioning - myself or others should be able to edit my snippets to improve them and have revisions save so that I can go back and use an older version if I prefer.
straightforward UI with minimal advertising if any
Does anyone know of a solution which meets these requirements? If not, would anyone be interested in something like this? As a software engineer, after step zero (does it already exist), I'm perfectly willing to go onto step 1 (would other people use it? If so, make it).
www.codebarrel.com
it has everything you asked for
Sounds like Gist.
http://gist.github.com/
Except for the tags part. But it might be workable anyway.
I'm working on a site for this. The very rough (as in: barely works, but not even functional yet) initial version is here: https://github.com/jasongrout/snippets
Given a project I'm about to start there will be documentation produced.
What is the best practice for this?
Should the documents live with the code and assets or should there be a separate documentation store?
Edit
I'd like a wiki but I will need to print the documents etc... It's a university project.
It really depends on your team. Where I work, we keep documentation in a wiki which is linked in with our team website. For the purposes of shipping documentation, the wiki can be exported and we run it through a parser that "fancifies" the look and feel of the documentation for customer purposes.
Storing the documentation with the code (typically in your source repository) is not a bad idea. Just make sure to keep them separated. For example, keep a docs folder which is on the same level with your src folder in your repository. This way, you can quickly ship the current documentation, you can easily track revisions, and anybody new to the project can immediately jump in without having to go to multiple locations for information.
Storing it in source control is fine.
This is an interesting question -- basically, what others are saying is right about generated documentation, source files and templates/etc. should be stored in source control and generated during your build process.
As far as requirements/specs/etc. documentation, I have worked both ways, and I very much prefer using SharePoint or a Wiki/document portal that is designed for document sharing/versioning. The reason is, most non-developer folks aren't comfortable working with source control systems, and you don't gain any of the advantages of intelligent merging if you are using a binary format like Word. Plus it's nice to have internet-based access so you can reference and work on the docs in a distributed team without people having to install extra software.
Here's a 2017 summary of the options and my experience:
(extreme 1) Completely external (e.g. a wiki, Google Docs, LaTeX, MS Word, MS Onedrive)
People aren't bothered about keeping it up to date (half of them don't even know where to find the page that needs updating since it's so out of the trenches).
wiki platforms are “captive user interfaces” - your data gets stored in their proprietary schemas and is not easy to examine with a simple text editor (Confluence is even worse in that you have no access to the plaintext content at all anymore)
(extreme 2) Completely internal (e.g. javadoc)
pollutes the source code, and is usually too low level to be of any use. Well-written source code is still the best form of low level documentation.
However, I feel package-info.java files are underutilized.
(balance) Colocated documentation (e.g. README.md)
A good half way solution, with the benefits of version control. If a single README.md file is not enough, consider a doc/ folder. The only drawback of this I've seen is whether to source control helpful graphics (e.g. png files) and risk bloating the repo.
One interesting way to avoid this problem is to use plaintext diagram tools (I find Grapheasy and Text Diagram to be a breath of fresh air).
plaintext can be easily read even if your rendering engine changes as the years go by.
Github's success is in no small part thanks to its README.md located in the root of the project.
One tiny disadvantage of this approach though is that your continuous integration system will trigger a new build each time you make edits to the README.md file.
If you are writing versioned user documentation associated with each release of the product, then it makes sense to put the documentation in source control along with its associated product release.
If you are writing internal developer documentation, use automated internal source code documentation (javadoc, doxygen, .net annotations, etc) for source level documentation and a project wiki for design level documentation.
I think most of us in the industry are not really following best-practices and it of course also depends a lot on your situation.
In an agile environment where you would have a very iterative process of release, you will want to "travel light". In this particular case, Jason's suggestion of a separate Wiki really works great.
In a water-fall/big bang model, you will have a better opportunity to have a decent documentation update with each new release. Also you will need to clearly document what version of the requirements was agreed on and have loads of documentation for every tiny change you do to requirements (due to the effects it has on subsequent stages). Often if the documentation can live together with the version controlled source code it is the best.
Are you using any sort of auto-documentation or is it completely manual? Assuming that you are using an auto-documentation system, the documentation is more or less generated on the fly, and would be part of the code itself.
To me, (assuming that it's possible with whatever code you are using), this would be the preferred method of handling it, as you wouldn't need to maintain the documentation source at all.