DOCSLIB.ORG

Development Tools Release 2017.11.14

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Development Tools Release 2017.11.14 Development tools Release 2017.11.14 Patrick Vergain 2017-12-9 Contents 1 Documentation 3 1.1 Documentation news...........................................3 1.1.1 Documentation news 2017...................................3 1.1.2 Documentation news 2016...................................3 1.2 Documentation Advices.........................................4 1.2.1 You are what you document (Monday, May 5, 2014).....................4 1.2.2 13 Things People Hate about Your Open Source Docs.....................5 1.2.3 Beautiful docs..........................................5 1.2.4 Designing Great API Docs (11 Jan 2012)...........................5 1.2.5 Docness.............................................5 1.2.6 Hacking distributed (february 2013)..............................6 1.2.7 Jacob Kaplan-Moss (November 10, 2009)...........................6 1.2.8 Agile documentation best practices...............................6 1.2.9 Best Practices for Documenting Technical Procedures Melanie Seibert............7 1.2.10 Plone..............................................7 1.2.11 Twilio..............................................7 1.2.12 Other advices..........................................7 1.3 Documentation generators........................................ 10 1.3.1 Sphinx.............................................. 10 1.3.2 Authorea............................................ 144 1.3.3 Doxygen............................................ 144 1.3.4 Javadoc............................................. 159 1.3.5 Jekyll.............................................. 159 1.3.6 JSDoc.............................................. 160 1.3.7 Mkdocs............................................. 161 1.3.8 Pandoc............................................. 161 1.4 Good documentation........................................... 164 1.4.1 CakePHP............................................ 164 1.4.2 Passlib.............................................. 164 1.4.3 Sfepy.............................................. 164 1.4.4 Shark.............................................. 164 1.5 Formats Documentation......................................... 165 1.5.1 Input formats.......................................... 165 1.5.2 Input/output formats...................................... 174 1.5.3 Output formats......................................... 175 1.6 Documentation projects......................................... 179 i 1.6.1 C Documentation projects................................... 179 1.6.2 Documenting python projects.................................. 179 1.7 Documentation tools........................................... 180 1.7.1 Dash............................................... 180 1.7.2 Graphviz............................................ 182 1.7.3 Zeal documentation browser.................................. 182 1.8 Documentation videos.......................................... 183 1.8.1 Write the docs.......................................... 183 1.8.2 RTFM - wRite The Friendly Manual.............................. 183 1.9 Wiki documentation........................................... 184 1.9.1 Mediawiki............................................ 184 1.9.2 Wiki tools............................................ 195 2 Command Line Interface (CLI) 201 2.1 Introduction............................................... 201 2.2 Usage................................................... 202 2.2.1 CLI and python......................................... 202 2.2.2 CLI with Perl.......................................... 202 2.2.3 Command Line Interface (CLI) on GNU/linux......................... 207 2.2.4 Command Line Interface (CLI) on Windows.......................... 219 2.2.5 Google cli............................................ 231 3 Databases 233 3.1 PostgreSQL database........................................... 233 3.1.1 PostgreSQL books....................................... 233 ii Development tools, Release 2017.11.14 pvbookmarks Release 2017.11.14 Date 2017-12-9 Authors Patrick Vergain Target About documentation and CLI See also: • genindex • https://github.com/pvergain/pvbookmarks • http://pvbookmarks.readthedocs.org/en/master/ Contents 1 Development tools, Release 2017.11.14 2 Contents CHAPTER 1 Documentation See also: • http://blog.smartbear.com/software-quality/bid/256072/13-reasons-your-open-source-docs-make-people-want-to-scream • http://brikis98.blogspot.de/2014/05/you-are-what-you-document.html 1.1 Documentation news 1.1.1 Documentation news 2017 Contents • Documentation news 2017 – Autodoc-style extraction into Sphinx for your JS project Autodoc-style extraction into Sphinx for your JS project See also: • sphinx-js : autodoc-style extraction into Sphinx for your JS project 1.1.2 Documentation news 2016 Contents • Documentation news 2016 3 Development tools, Release 2017.11.14 – La documentation linux utilise sphinx La documentation linux utilise sphinx See also: • https://github.com/return42/linuxdoc • https://return42.github.io/linuxdoc/ • https://lwn.net/Articles/692704/ L’annonce sur https://lwn.net/Articles/692704/ 1.2 Documentation Advices See also: • parse_API_doc • http://producingoss.com/en/getting-started.html • http://justwriteclick.com/book/ • http://brikis98.blogspot.de/2014/05/you-are-what-you-document.html Contents • Documentation Advices – You are what you document (Monday, May 5, 2014) – 13 Things People Hate about Your Open Source Docs – Beautiful docs – Designing Great API Docs (11 Jan 2012) – Docness * Docness Source code – Hacking distributed (february 2013) – Jacob Kaplan-Moss (November 10, 2009) – Agile documentation best practices – Best Practices for Documenting Technical Procedures Melanie Seibert – Plone – Twilio – Other advices 1.2.1 You are what you document (Monday, May 5, 2014) See also: 4 Chapter 1. Documentation Development tools, Release 2017.11.14 • http://brikis98.blogspot.de/2014/05/you-are-what-you-document.html • http://jacobian.org/writing/great-documentation/ • http://zachholman.com/posts/documentation/ • http://blog.parse.com/2012/01/11/designing-great-api-docs/ • http://www.mikepope.com/blog/DisplayBlog.aspx?permalink=1680 • https://github.com/PharkMillups/beautiful-docs • http://blog.codinghorror.com/if-it-isnt-documented-it-doesnt-exist/ • http://docs.writethedocs.org/writing/beginners-guide-to-docs/ The number one cause of startup failure is not the product, but the distribution: it doesn’t matter how good the product is if no one uses it. With software, the documentation is the distribution: it doesn’t matter how good the code is if no one uses it. If it isn’t documented, it doesn’t exist. 1.2.2 13 Things People Hate about Your Open Source Docs See also: • http://blog.smartbear.com/careers/13-things-people-hate-about-your-open-source-docs/ • http://www.framablog.org/index.php/post/2013/06/28/documentation-defauts-open-source 1.2.3 Beautiful docs See also: • https://github.com/PharkMillups/beautiful-docs 1.2.4 Designing Great API Docs (11 Jan 2012) See also: • http://blog.parse.com/2012/01/11/designing-great-api-docs/ 1.2.5 Docness See also: • http://docness.readthedocs.org/ • http://docness.readthedocs.org/en/latest/documentation-is-part-of-product.html Consider the documentation as a component of your product, i.e. don’t package it as an external product or as an option. In software development, your “product” is usually made of the software, which itself is usually based on source code. 1.2. Documentation Advices 5 Development tools, Release 2017.11.14 Docness Source code See also: https://github.com/benoitbryon/docness 1.2.6 Hacking distributed (february 2013) See also: • http://hackingdistributed.com/2013/02/11/principled-documentation/ In the beginning, there was no documentation. These days, infrastructure software has terrible documentation. Take heed of these commandments, for, among hackers, judgment day is every day. 1.2.7 Jacob Kaplan-Moss (November 10, 2009) See also: http://jacobian.org/writing/great-documentation/what-to-write/ 1.2.8 Agile documentation best practices See also: • http://www.agilemodeling.com/essays/agileDocumentationBestPractices.htm • http://www.agilemodeling.com/essays/agileDocumentationBestPractices.htm#sthash.nuUKabMJ.dpuf Ideally, an agile document is just barely good enough, or just barely sufficient, for the situation at hand. Documentation is an important part of agile software development projects, but unlike traditionalists who often see documentation as a risk reduction strategy, agilists typically see documentation as a strategy which increases overall project risk and therefore strive to be as efficient as possible when it comes to documentation. Agilists write documentation when that’s the best way to achieve the relevant goals, but there often proves to be better ways to achieve those goals than writing static documentation. This article summarizes common “best practices” which agilists have adopted with respect to documentation. Best practices for increasing the agility of documentation: Writing Prefer executable specifications over static documents Document stable concepts, not speculative ideas Gen- erate system documentation Simplification Keep documentation just simple enough, but not too simple Write the fewest documents with least overlap Put the information in the most appropriate place Display information publicly Determining What to Document Document with a purpose Focus on the needs of the actual customers(s) of the document The customer determines sufficiency Determining When to Document Iterate, iterate, iterate Find better ways to communicate
Load more

Recommended publications
  • Usask Open Textbook Authoring Guide – Ver.1.0
    USask Open Textbook Authoring Guide – Ver.1.0 USask Open Textbook Authoring Guide – Ver.1.0 A Guide to Authoring & Adapting Open Textbooks at the University of Saskatchewan Distance Education Unit (DEU), University of Saskatchewan Jordan Epp, M.Ed., Kristine Dreaver-Charles, M.Sc.Ed., Jeanette McKee, M.Ed. Open Press DEU, Usask Saskatoon Copyright:2016 by Distance Education Unit, University of Saskatchewan. This book is an adaptation based on the B.C. Open Textbook Authoring Guide created by BCcampus and licensed with a CC-BY 4.0 license. Changes to the BCcampus Authoring Guide for this University of Saskatchewan adaptation included: Changing the references from BCcampus Open Project to be more relevant to the University of Saskatchewan’s open textbook development. Creation of a new title page and book title. Changing information about Support Services to be University of Saskatchewan specific. Performing a general text edit throughout the guide, added image captions, and updated most images to remove the BCcampus branding. Updating Pressbook platform nomenclature to be consistent with the current version of Pressbooks. Unless otherwise noted, this book is released under a Creative Commons Attribution (CC-BY) 4.0 Unported license. Under the terms of the CC-BY license you can freely share, copy or redistribute the material in any medium or format, or adapt the material by remixing, transforming or modifying this material providing you attribute the Distance Education Unit, University of Saskatchewan and BCcampus. Attribution means you must give appropriate credit to the Distance Education Unit, University of Saskatchewan and BCcampus as the original creator, note the CC-BY license this document has been released under, and indicate if you have made any changes to the content.
    [Show full text]
  • Tuto Documentation Release 0.1.0
    Tuto Documentation Release 0.1.0 DevOps people 2020-05-09 09H16 CONTENTS 1 Documentation news 3 1.1 Documentation news 2020........................................3 1.1.1 New features of sphinx.ext.autodoc (typing) in sphinx 2.4.0 (2020-02-09)..........3 1.1.2 Hypermodern Python Chapter 5: Documentation (2020-01-29) by https://twitter.com/cjolowicz/..................................3 1.2 Documentation news 2018........................................4 1.2.1 Pratical sphinx (2018-05-12, pycon2018)...........................4 1.2.2 Markdown Descriptions on PyPI (2018-03-16)........................4 1.2.3 Bringing interactive examples to MDN.............................5 1.3 Documentation news 2017........................................5 1.3.1 Autodoc-style extraction into Sphinx for your JS project...................5 1.4 Documentation news 2016........................................5 1.4.1 La documentation linux utilise sphinx.............................5 2 Documentation Advices 7 2.1 You are what you document (Monday, May 5, 2014)..........................8 2.2 Rédaction technique...........................................8 2.2.1 Libérez vos informations de leurs silos.............................8 2.2.2 Intégrer la documentation aux processus de développement..................8 2.3 13 Things People Hate about Your Open Source Docs.........................9 2.4 Beautiful docs.............................................. 10 2.5 Designing Great API Docs (11 Jan 2012)................................ 10 2.6 Docness.................................................
    [Show full text]
  • Markdown Markup Languages What Is Markdown? Symbol
    Markdown What is Markdown? ● Markdown is a lightweight markup language with plain text formatting syntax. Péter Jeszenszky – See: https://en.wikipedia.org/wiki/Markdown Faculty of Informatics, University of Debrecen [email protected] Last modified: October 4, 2019 3 Markup Languages Symbol ● Markup languages are computer languages for annotating ● Dustin Curtis. The Markdown Mark. text. https://dcurt.is/the-markdown-mark – They allow the association of metadata with parts of text in a https://github.com/dcurtis/markdown-mark clearly distinguishable way. ● Examples: – TeX, LaTeX https://www.latex-project.org/ – Markdown https://daringfireball.net/projects/markdown/ – troff (man pages) https://www.gnu.org/software/groff/ – XML https://www.w3.org/XML/ – Wikitext https://en.wikipedia.org/wiki/Help:Wikitext 2 4 Characteristics Usage (2) ● An easy-to-read and easy-to-write plain text ● Collaboration platforms and tools: format that. – GitHub https://github.com/ ● Can be converted to various output formats ● See: Writing on GitHub (e.g., HTML). https://help.github.com/en/categories/writing-on-github – Trello https://trello.com/ ● Specifically targeted at non-technical users. ● See: How To Format Your Text in Trello ● The syntax is mostly inspired by the format of https://help.trello.com/article/821-using-markdown-in-trell o plain text email. 5 7 Usage (1) Usage (3) ● Markdown is widely used on the web for ● Blogging platforms and content management entering text. systems: – ● The main application areas include: Ghost https://ghost.org/
    [Show full text]
  • C-C++ Beautifier HOW-TO
    C-C++ Beautifier HOW-TO Al Dev (Alavoor Vasudevan) < alavoor[AT]yahoo.com > v16.7, 2 Nov 2003 Abstract This document will help you to format (beautify) the C/C++ programs so that it is more readable and confirms to your site C/C++ coding standards. The information in this document applies to all the operating sytems that is - Lin- ux, MS DOS, Apple Macintosh, Windows 95/NT/2000, BeOS, OS/2, IBM OSes, all flavors of Unix like Solaris, HPUX, AIX, SCO, Sinix, BSD, UnixWare, etc.. and to all other operating systems which support "C" compiler (it means almost all the operating systems on this planet!). Table of Contents Introduction ...................................................................................................................... 1 Installing BCPP ................................................................................................................. 2 How can I trust Beautifier programs??!! ................................................................................ 3 Method 1: Verfication Program for C++/C ..................................................................... 3 Method 2: Verfication Program for C++/C ..................................................................... 3 Method 3: Verfication Program for Java/C++/Others ........................................................ 4 Method 4: Shell script: Verfication Program for C++/C .................................................... 5 HTML Beautifier ..............................................................................................................
    [Show full text]
  • Vulnerability Summary for the Week of September 4, 2017
    Vulnerability Summary for the Week of September 4, 2017 The vulnerabilities are based on the CVE vulnerability naming standard and are organized according to severity, determined by the Common Vulnerability Scoring System (CVSS) standard. The division of high, medium, and low severities correspond to the following scores: High - Vulnerabilities will be labeled High severity if they have a CVSS base score of 7.0 - 10.0 Medium - Vulnerabilities will be labeled Medium severity if they have a CVSS base score of 4.0 - 6.9 Low - Vulnerabilities will be labeled Low severity if they have a CVSS base score of 0.0 - 3.9 High Vulnerabilities CVS S Primary Publishe Scor Source & Vendor -- Product Description d e Patch Info In libavformat/mxfdec.c in FFmpeg 3.3.3, a DoS in mxf_read_index_entry_array() due to lack of an EOF (End of File) check might cause huge CPU consumption. When a crafted MXF file, which claims a large "nb_index_entries" field in the header but does not contain sufficient backing data, is provided, the loop would consume huge CPU resources, since there is no EOF check inside the loop. Moreover, this big loop can be CVE-2017- invoked multiple times if there is more than 14170 one applicable data segment in the crafted 2017-09- CONFIRM(lin ffmpeg -- ffmpeg MXF file. 07 7.1 k is external) In libavformat/nsvdec.c in FFmpeg 3.3.3, a DoS in nsv_parse_NSVf_header() due to lack of an EOF (End of File) check might cause huge CPU consumption. When a crafted NSV file, which claims a large "table_entries_used" field in the header but does not contain sufficient backing data, is CVE-2017- provided, the loop over 'table_entries_used' 14171 would consume huge CPU resources, since 2017-09- CONFIRM(lin ffmpeg -- ffmpeg there is no EOF check inside the loop.
    [Show full text]
  • Unifying Modeling and Programming with ALF
    SOFTENG 2016 : The Second International Conference on Advances and Trends in Software Engineering Unifying Modeling and Programming with ALF Thomas Buchmann and Alexander Rimer University of Bayreuth Chair of Applied Computer Science I Bayreuth, Germany email: fthomas.buchmann, [email protected] Abstract—Model-driven software engineering has become more The Eclipse Modeling Framework (EMF) [5] has been and more popular during the last decade. While modeling the established as an extensible platform for the development of static structure of a software system is almost state-of-the art MDSE applications. It is based on the Ecore meta-model, nowadays, programming is still required to supply behavior, i.e., which is compatible with the Object Management Group method bodies. Unified Modeling Language (UML) class dia- (OMG) Meta Object Facility (MOF) specification [6]. Ideally, grams constitute the standard in structural modeling. Behavioral software engineers operate only on the level of models such modeling, on the other hand, may be achieved graphically with a set of UML diagrams or with textual languages. Unfortunately, that there is no need to inspect or edit the actual source code, not all UML diagrams come with a precisely defined execution which is generated from the models automatically. However, semantics and thus, code generation is hindered. In this paper, an practical experiences have shown that language-specific adap- implementation of the Action Language for Foundational UML tations to the generated source code are frequently necessary. (Alf) standard is presented, which allows for textual modeling In EMF, for instance, only structure is modeled by means of of software systems.
    [Show full text]
  • The R Journal Volume 4/2, December 2012
    The Journal Volume 4/2, December 2012 A peer-reviewed, open-access publication of the R Foundation for Statistical Computing Contents Editorial . .3 Contributed Research Articles What’s in a Name? . .5 It’s Not What You Draw, It’s What You Don’t Draw . 13 Debugging grid Graphics . 19 frailtyHL: A Package for Fitting Frailty Models with H-likelihood . 28 influence.ME: Tools for Detecting Influential Data in Mixed Effects Models . 38 The crs Package: Nonparametric Regression Splines for Continuous and Categorical Predic- tors.................................................... 48 Rfit: Rank-based Estimation for Linear Models . 57 Graphical Markov Models with Mixed Graphs in R . 65 Programmer’s Niche The State of Naming Conventions in R . 74 News and Notes Changes in R . 76 Changes on CRAN . 80 News from the Bioconductor Project . 101 R Foundation News . 102 2 The Journal is a peer-reviewed publication of the R Foun- dation for Statistical Computing. Communications regarding this pub- lication should be addressed to the editors. All articles are licensed un- der the Creative Commons Attribution 3.0 Unported license (CC BY 3.0, http://creativecommons.org/licenses/by/3.0/). Prospective authors will find detailed and up-to-date submission in- structions on the Journal’s homepage. Editor-in-Chief: Martyn Plummer Editorial Board: Heather Turner, Hadley Wickham, and Deepayan Sarkar Editor Help Desk: Uwe Ligges Editor Book Reviews: G. Jay Kerns Department of Mathematics and Statistics Youngstown State University Youngstown, Ohio 44555-0002 USA [email protected] R Journal Homepage: http://journal.r-project.org/ Email of editors and editorial board: [email protected] The R Journal is indexed/abstracted by EBSCO, DOAJ, Thomson Reuters.
    [Show full text]
  • Plantuml Language Reference Guide (Version 1.2021.2)
    Drawing UML with PlantUML PlantUML Language Reference Guide (Version 1.2021.2) PlantUML is a component that allows to quickly write : • Sequence diagram • Usecase diagram • Class diagram • Object diagram • Activity diagram • Component diagram • Deployment diagram • State diagram • Timing diagram The following non-UML diagrams are also supported: • JSON Data • YAML Data • Network diagram (nwdiag) • Wireframe graphical interface • Archimate diagram • Specification and Description Language (SDL) • Ditaa diagram • Gantt diagram • MindMap diagram • Work Breakdown Structure diagram • Mathematic with AsciiMath or JLaTeXMath notation • Entity Relationship diagram Diagrams are defined using a simple and intuitive language. 1 SEQUENCE DIAGRAM 1 Sequence Diagram 1.1 Basic examples The sequence -> is used to draw a message between two participants. Participants do not have to be explicitly declared. To have a dotted arrow, you use --> It is also possible to use <- and <--. That does not change the drawing, but may improve readability. Note that this is only true for sequence diagrams, rules are different for the other diagrams. @startuml Alice -> Bob: Authentication Request Bob --> Alice: Authentication Response Alice -> Bob: Another authentication Request Alice <-- Bob: Another authentication Response @enduml 1.2 Declaring participant If the keyword participant is used to declare a participant, more control on that participant is possible. The order of declaration will be the (default) order of display. Using these other keywords to declare participants
    [Show full text]
  • Howtos with Linuxdoc
    HOWTOs with LinuxDoc David S. Lawyer v0.09, November 2007 Questo testo tratta di come scrivere gli HOWTO usando il semplice linguaggio a marcatori (markup) LinuxDoc. È rivolto principalmente agli autori del Linux Documentation Project (e ad autori futuri alle prime armi che vogliono iniziare rapidamente). Se si vuole usare DocBook, il linguaggio a marcatori più completo e dicile, (incluso XML), vedere la LDP Authoring Guide (Guida per gli autori di LDP). Traduzione ed adattamenti in italiano a cura di Beatrice Torracca, beatricet (at) libero (dot) it, e Hugh Hartmann, hhartmann (at) libero (dot) it, revisione a cura di Vieri Giugni, v.giugni (at) gmail (dot) com). Per versioni aggiornate di questo documento, e per trovare altra documentazione in italiano sul software libero, visitare il sito dell' ILDP <http://it.ildp.org> Indice 1 Introduzione 2 1.1 Per partire immediatamente.....................................2 1.2 Copyright e licenza..........................................3 1.3 Perché si dovrebbe scrivere un HOWTO?.............................3 1.4 Perché ho scritto questo documento................................3 2 Informazioni sulla scrittura di un HOWTO3 2.1 Copyright...............................................3 2.2 Scegliere un argomento........................................3 3 Il formato degli HOWTO4 3.1 Introduzione..............................................4 4 LinuxDoc e DocBook a confronto4 5 Imparare LinuxDoc 6 5.1 Introduzione..............................................6 5.2 Esempio 1 (nome le: esempio1.sgml)...............................6 5.3 Esempio 2 (nome le: esempio2.sgml)...............................7 5.4 Esempio 3 (nome le: esempio3.sgml)...............................9 5.5 Guida di consultazione rapida di LinuxDoc............................ 11 5.5.1 Intestazione.......................................... 11 5.5.2 Impaginazione del corpo................................... 12 5.5.3 Tipi di carattere....................................... 12 1.
    [Show full text]
  • Open-Source Documentation
    Open-Source Documentation: In Search of User-Driven, Just-in-Time Writing Erik Berglund Michael Priestley Linköping University IBM Toronto Lab S-581 83, Linköping, Canada Sweden [email protected] + 46 13 28 24 93 [email protected] ABSTRACT Keywords Iterative development models allow developers to respond quickly Open source documentation, just-in-time, user-driven. to changing user requirements, but place increasing demands on writers who must handle increasing amounts of change with ever- 1. THE PROBLEM decreasing resources. In the software development world, one Over the years, the software industry has accepted that changing solution to this problem is open-source development: allowing the requirements are simply part of the software development process. users to set requirements and priorities by actually contributing to An allowance for client requirements change, even an expectation the development of the software. This results in just-in-time of change, is at the foundation of most software development software improvements that are explicitly user-driven, since they methodologies. The Rational Unified Process (RUP) illustrates are actually developed by users. this, and Extreme Programming (XP) exemplifies it. Taken to the In this article we will discuss how the open source model can be extreme, as it often is in open-source development, the extended to the development of documentation. In many open- functionality of the product may not be determined until the day it source projects, the role of writer has remained unchanged: is completed. documentation development remains a specialized activity, owned Continuous requirements change makes traditional methods of by a single writer or group of writers, who work as best they can software documentation difficult.
    [Show full text]
  • Asynchronous Intrusion Recovery for Interconnected Web Services
    Asynchronous intrusion recovery for interconnected web services The MIT Faculty has made this article openly available. Please share how this access benefits you. Your story matters. Citation Chandra, Ramesh, Taesoo Kim, and Nickolai Zeldovich. “Asynchronous Intrusion Recovery for Interconnected Web Services.” Proceedings of the Twenty-Fourth ACM Symposium on Operating Systems Principles - SOSP ’13 (2013), Nov. 3-6, 2013, Farminton, Pennsylvania, USA. ACM. As Published http://dx.doi.org/10.1145/2517349.2522725 Publisher Association for Computing Machinery Version Author's final manuscript Citable link http://hdl.handle.net/1721.1/91473 Terms of Use Creative Commons Attribution-Noncommercial-Share Alike Detailed Terms http://creativecommons.org/licenses/by-nc-sa/4.0/ Asynchronous intrusion recovery for interconnected web services Ramesh Chandra, Taesoo Kim, and Nickolai Zeldovich MIT CSAIL Abstract in the access control service, she could give herself write access to the employee management service, use these Recovering from attacks in an interconnected system is new-found privileges to make unauthorized changes to difficult, because an adversary that gains access to one employee data, and corrupt other services. Manually re- part of the system may propagate to many others, and covering from such an intrusion requires significant effort tracking down and recovering from such an attack re- to track down what services were affected by the attack quires significant manual effort. Web services are an and what changes were made by the attacker. important example of an interconnected system, as they are increasingly using protocols such as OAuth and REST Many web services interact with one another using pro- APIs to integrate with one another.
    [Show full text]
  • 7 Best Free Flowchart Tools for Windows
    2018. 6. 1. Pocket: 7 Best Free Flowchart Tools for Windows 7 Best Free Flowchart Tools for Windows By Joel Lee, www.makeuseof.com 6월 20일, 2017 Flowcharts aren’t just for engineers, programmers, and managers. Everyone can benet from learning how to make owcharts, most notably as a way to streamline your work and life, but even to break free from bad habits. The only problem is, what’s the best way to make a owchart? Plenty of top-notch owcharting apps exist, but they can get pricey. Microsoft Visio, the most popular option, is $300 (standalone) or $13 per month (on top of Oce 365). ConceptDraw Pro is $200. Edraw Max is $180. MyDraw is $70. Is it really necessary to spend so much on a owcharting tool? No! There are plenty of free options that are more than good enough, especially for non-business uses. You can either learn to create stunning owcharts in Microsoft Word How to Create Stunning Flowcharts With Microsoft Word How to Create Stunning Flowcharts With Microsoft Word Used with imagination, owcharts can simplify both your work or life. Why not try out a few owcharts with one of the easiest tools on hand – Microsoft Word. Read More if you already have it or use one of the following free Windows apps. Web-based apps have been intentionally excluded. 1. Dia Dia is a free and full-featured owchart app. It’s also entirely open source under the GPLv2 license, which is great if you adhere to open source philosophy. It’s powerful, extensible, and easy to use.
    [Show full text]