I am quite confused a bit when sometime people say the word "artifact". For example, please show me the artifact. Anyone could give me an example what the artifact mean and when we should say it? Why don't say that document or this library or something clearer. and What is the difference between artifact and tool?
Thanks in advance
Updated
Let me answer my question. After research in Wiki https://en.wikipedia.org/wiki/Artifact_(software_development) , I can conclude that the word artifact is just some output during software development of each phase. For example, during collecting user's requirement, the artifact may be a document like user requirement specification.
During coding a program, the artifact might be output - that you workout like - source code that you will deliver or use in another phase such as code review and testing.
Hope my answer will help anyone who uncertain the meaning of this word.
Regards.
Let me answer my question. After research in Wiki https://en.wikipedia.org/wiki/Artifact_(software_development) , I can conclude that the word artifact is just some output during software development of each phase. For example, during collecting user's requirement, the artifact may be a document like user requirement specification.
During coding a program, the artifact might be output - that you workout like - source code that you will deliver or use in another phase such as code review and testing.
Hope my answer will help anyone who uncertain the meaning of this word.
Regards.
Related
Good morning,
This morning I tried to put an issue on Github but it was impossible.
https://github.com/spring-projects/spring-data-jpa
I was reviewing the technical documentation and I noticed that from last month, the project don´t generate the documentation on PDF.
Last release with Documentation on PDF version:
https://docs.spring.io/spring-data/jpa/docs/2.0.5.RELEASE/reference/
Any reason to not generate the PDF?
Many thanks in advance
Juan Antonio
Turn out there is actually already a PR for this: https://github.com/spring-projects/spring-data-build/pull/545
Or at least the infrastructure to achieve this.
Hopes are the team will be able to merge this before the GA release, but since it is just additional formats an not actual contents, let alone features it hasn't the highest priority.
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.
I have self skilled on MATLAB basics and its functionalities. However I found that project implementation in MATLAB is subject to theoretical information on same domain. Being from a non-engineering field I am finding it quiet difficult to implement short projects.
I tried to search for websites which has a few free MATLAB projects source code available or MATLAB projects source code hosted - I wished to pursue, read and parse the implementation, but could not find any. Website either hosted the zip file having empty / incomplete codes.
Please let me know if there is a genuine / good website where free MATLAB project source code is available? It would be best if it has something related to DSP, Image Processing and Numerical Analysis.
Thanks in advance.
http://www.mathworks.com/matlabcentral/fileexchange/
there are many many solved problems there.
look for the higher rated ones, and read through.
enjoy
I found the textbook by Maghrab to be very useful.
http://amzn.com/B008ITDEKI
It is not a website, but it was really quite good.
When you say 'projects' do you mean engineering-related tasks, or do you mean something else?
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.