Merge branch 'master' of ssh://forge.cadoles.com:4242/cadoles/formations

algorithmique/cours/Makefile

@@ -0,0 +1,216 @@
+# Makefile for Sphinx documentation
+#
+
+# You can set these variables from the command line.
+SPHINXOPTS    =
+SPHINXBUILD   = sphinx-build
+PAPER         =
+BUILDDIR      = _build
+
+# User-friendly check for sphinx-build
+ifeq ($(shell which $(SPHINXBUILD) >/dev/null 2>&1; echo $$?), 1)
+$(error The '$(SPHINXBUILD)' command was not found. Make sure you have Sphinx installed, then set the SPHINXBUILD environment variable to point to the full path of the '$(SPHINXBUILD)' executable. Alternatively you can add the directory with the executable to your PATH. If you don't have Sphinx installed, grab it from http://sphinx-doc.org/)
+endif
+
+# Internal variables.
+PAPEROPT_a4     = -D latex_paper_size=a4
+PAPEROPT_letter = -D latex_paper_size=letter
+ALLSPHINXOPTS   = -d $(BUILDDIR)/doctrees $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) .
+# the i18n builder cannot share the environment and doctrees with the others
+I18NSPHINXOPTS  = $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) .
+
+.PHONY: help
+help:
+	@echo "Please use \`make <target>' where <target> is one of"
+	@echo "  html       to make standalone HTML files"
+	@echo "  dirhtml    to make HTML files named index.html in directories"
+	@echo "  singlehtml to make a single large HTML file"
+	@echo "  pickle     to make pickle files"
+	@echo "  json       to make JSON files"
+	@echo "  htmlhelp   to make HTML files and a HTML help project"
+	@echo "  qthelp     to make HTML files and a qthelp project"
+	@echo "  applehelp  to make an Apple Help Book"
+	@echo "  devhelp    to make HTML files and a Devhelp project"
+	@echo "  epub       to make an epub"
+	@echo "  latex      to make LaTeX files, you can set PAPER=a4 or PAPER=letter"
+	@echo "  latexpdf   to make LaTeX files and run them through pdflatex"
+	@echo "  latexpdfja to make LaTeX files and run them through platex/dvipdfmx"
+	@echo "  text       to make text files"
+	@echo "  man        to make manual pages"
+	@echo "  texinfo    to make Texinfo files"
+	@echo "  info       to make Texinfo files and run them through makeinfo"
+	@echo "  gettext    to make PO message catalogs"
+	@echo "  changes    to make an overview of all changed/added/deprecated items"
+	@echo "  xml        to make Docutils-native XML files"
+	@echo "  pseudoxml  to make pseudoxml-XML files for display purposes"
+	@echo "  linkcheck  to check all external links for integrity"
+	@echo "  doctest    to run all doctests embedded in the documentation (if enabled)"
+	@echo "  coverage   to run coverage check of the documentation (if enabled)"
+
+.PHONY: clean
+clean:
+	rm -rf $(BUILDDIR)/*
+
+.PHONY: html
+html:
+	$(SPHINXBUILD) -b html $(ALLSPHINXOPTS) $(BUILDDIR)/html
+	@echo
+	@echo "Build finished. The HTML pages are in $(BUILDDIR)/html."
+
+.PHONY: dirhtml
+dirhtml:
+	$(SPHINXBUILD) -b dirhtml $(ALLSPHINXOPTS) $(BUILDDIR)/dirhtml
+	@echo
+	@echo "Build finished. The HTML pages are in $(BUILDDIR)/dirhtml."
+
+.PHONY: singlehtml
+singlehtml:
+	$(SPHINXBUILD) -b singlehtml $(ALLSPHINXOPTS) $(BUILDDIR)/singlehtml
+	@echo
+	@echo "Build finished. The HTML page is in $(BUILDDIR)/singlehtml."
+
+.PHONY: pickle
+pickle:
+	$(SPHINXBUILD) -b pickle $(ALLSPHINXOPTS) $(BUILDDIR)/pickle
+	@echo
+	@echo "Build finished; now you can process the pickle files."
+
+.PHONY: json
+json:
+	$(SPHINXBUILD) -b json $(ALLSPHINXOPTS) $(BUILDDIR)/json
+	@echo
+	@echo "Build finished; now you can process the JSON files."
+
+.PHONY: htmlhelp
+htmlhelp:
+	$(SPHINXBUILD) -b htmlhelp $(ALLSPHINXOPTS) $(BUILDDIR)/htmlhelp
+	@echo
+	@echo "Build finished; now you can run HTML Help Workshop with the" \
+	      ".hhp project file in $(BUILDDIR)/htmlhelp."
+
+.PHONY: qthelp
+qthelp:
+	$(SPHINXBUILD) -b qthelp $(ALLSPHINXOPTS) $(BUILDDIR)/qthelp
+	@echo
+	@echo "Build finished; now you can run "qcollectiongenerator" with the" \
+	      ".qhcp project file in $(BUILDDIR)/qthelp, like this:"
+	@echo "# qcollectiongenerator $(BUILDDIR)/qthelp/Algorithmique.qhcp"
+	@echo "To view the help file:"
+	@echo "# assistant -collectionFile $(BUILDDIR)/qthelp/Algorithmique.qhc"
+
+.PHONY: applehelp
+applehelp:
+	$(SPHINXBUILD) -b applehelp $(ALLSPHINXOPTS) $(BUILDDIR)/applehelp
+	@echo
+	@echo "Build finished. The help book is in $(BUILDDIR)/applehelp."
+	@echo "N.B. You won't be able to view it unless you put it in" \
+	      "~/Library/Documentation/Help or install it in your application" \
+	      "bundle."
+
+.PHONY: devhelp
+devhelp:
+	$(SPHINXBUILD) -b devhelp $(ALLSPHINXOPTS) $(BUILDDIR)/devhelp
+	@echo
+	@echo "Build finished."
+	@echo "To view the help file:"
+	@echo "# mkdir -p $$HOME/.local/share/devhelp/Algorithmique"
+	@echo "# ln -s $(BUILDDIR)/devhelp $$HOME/.local/share/devhelp/Algorithmique"
+	@echo "# devhelp"
+
+.PHONY: epub
+epub:
+	$(SPHINXBUILD) -b epub $(ALLSPHINXOPTS) $(BUILDDIR)/epub
+	@echo
+	@echo "Build finished. The epub file is in $(BUILDDIR)/epub."
+
+.PHONY: latex
+latex:
+	$(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex
+	@echo
+	@echo "Build finished; the LaTeX files are in $(BUILDDIR)/latex."
+	@echo "Run \`make' in that directory to run these through (pdf)latex" \
+	      "(use \`make latexpdf' here to do that automatically)."
+
+.PHONY: latexpdf
+latexpdf:
+	$(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex
+	@echo "Running LaTeX files through pdflatex..."
+	$(MAKE) -C $(BUILDDIR)/latex all-pdf
+	@echo "pdflatex finished; the PDF files are in $(BUILDDIR)/latex."
+
+.PHONY: latexpdfja
+latexpdfja:
+	$(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex
+	@echo "Running LaTeX files through platex and dvipdfmx..."
+	$(MAKE) -C $(BUILDDIR)/latex all-pdf-ja
+	@echo "pdflatex finished; the PDF files are in $(BUILDDIR)/latex."
+
+.PHONY: text
+text:
+	$(SPHINXBUILD) -b text $(ALLSPHINXOPTS) $(BUILDDIR)/text
+	@echo
+	@echo "Build finished. The text files are in $(BUILDDIR)/text."
+
+.PHONY: man
+man:
+	$(SPHINXBUILD) -b man $(ALLSPHINXOPTS) $(BUILDDIR)/man
+	@echo
+	@echo "Build finished. The manual pages are in $(BUILDDIR)/man."
+
+.PHONY: texinfo
+texinfo:
+	$(SPHINXBUILD) -b texinfo $(ALLSPHINXOPTS) $(BUILDDIR)/texinfo
+	@echo
+	@echo "Build finished. The Texinfo files are in $(BUILDDIR)/texinfo."
+	@echo "Run \`make' in that directory to run these through makeinfo" \
+	      "(use \`make info' here to do that automatically)."
+
+.PHONY: info
+info:
+	$(SPHINXBUILD) -b texinfo $(ALLSPHINXOPTS) $(BUILDDIR)/texinfo
+	@echo "Running Texinfo files through makeinfo..."
+	make -C $(BUILDDIR)/texinfo info
+	@echo "makeinfo finished; the Info files are in $(BUILDDIR)/texinfo."
+
+.PHONY: gettext
+gettext:
+	$(SPHINXBUILD) -b gettext $(I18NSPHINXOPTS) $(BUILDDIR)/locale
+	@echo
+	@echo "Build finished. The message catalogs are in $(BUILDDIR)/locale."
+
+.PHONY: changes
+changes:
+	$(SPHINXBUILD) -b changes $(ALLSPHINXOPTS) $(BUILDDIR)/changes
+	@echo
+	@echo "The overview file is in $(BUILDDIR)/changes."
+
+.PHONY: linkcheck
+linkcheck:
+	$(SPHINXBUILD) -b linkcheck $(ALLSPHINXOPTS) $(BUILDDIR)/linkcheck
+	@echo
+	@echo "Link check complete; look for any errors in the above output " \
+	      "or in $(BUILDDIR)/linkcheck/output.txt."
+
+.PHONY: doctest
+doctest:
+	$(SPHINXBUILD) -b doctest $(ALLSPHINXOPTS) $(BUILDDIR)/doctest
+	@echo "Testing of doctests in the sources finished, look at the " \
+	      "results in $(BUILDDIR)/doctest/output.txt."
+
+.PHONY: coverage
+coverage:
+	$(SPHINXBUILD) -b coverage $(ALLSPHINXOPTS) $(BUILDDIR)/coverage
+	@echo "Testing of coverage in the sources finished, look at the " \
+	      "results in $(BUILDDIR)/coverage/python.txt."
+
+.PHONY: xml
+xml:
+	$(SPHINXBUILD) -b xml $(ALLSPHINXOPTS) $(BUILDDIR)/xml
+	@echo
+	@echo "Build finished. The XML files are in $(BUILDDIR)/xml."
+
+.PHONY: pseudoxml
+pseudoxml:
+	$(SPHINXBUILD) -b pseudoxml $(ALLSPHINXOPTS) $(BUILDDIR)/pseudoxml
+	@echo
+	@echo "Build finished. The pseudo-XML files are in $(BUILDDIR)/pseudoxml."

algorithmique/cours/conf.py

@@ -0,0 +1,355 @@
+# -*- coding: utf-8 -*-
+#
+# Algorithmique documentation build configuration file, created by
+# sphinx-quickstart on Thu Mar 16 16:07:00 2017.
+#
+# This file is execfile()d with the current directory set to its
+# containing dir.
+#
+# Note that not all possible configuration values are present in this
+# autogenerated file.
+#
+# All configuration values have a default; values that are commented out
+# serve to show the default.
+
+import sys
+import os
+
+# If extensions (or modules to document with autodoc) are in another directory,
+# add these directories to sys.path here. If the directory is relative to the
+# documentation root, use os.path.abspath to make it absolute, like shown here.
+#sys.path.insert(0, os.path.abspath('.'))
+
+# -- General configuration ------------------------------------------------
+
+# If your documentation needs a minimal Sphinx version, state it here.
+#needs_sphinx = '1.0'
+
+# Add any Sphinx extension module names here, as strings. They can be
+# extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
+# ones.
+extensions = [
+    'sphinx.ext.pngmath',
+]
+
+# Add any paths that contain templates here, relative to this directory.
+templates_path = ['_templates']
+
+# The suffix(es) of source filenames.
+# You can specify multiple suffix as a list of string:
+# source_suffix = ['.rst', '.md']
+source_suffix = '.txt'
+
+# The encoding of source files.
+#source_encoding = 'utf-8-sig'
+
+# The master toctree document.
+master_doc = 'index'
+
+# General information about the project.
+project = u'Algorithmique'
+copyright = u'2017, Gwen'
+author = u'Gwen'
+
+# The version info for the project you're documenting, acts as replacement for
+# |version| and |release|, also used in various other places throughout the
+# built documents.
+#
+# The short X.Y version.
+version = u'1'
+# The full version, including alpha/beta/rc tags.
+release = u'1'
+
+# The language for content autogenerated by Sphinx. Refer to documentation
+# for a list of supported languages.
+#
+# This is also used if you do content translation via gettext catalogs.
+# Usually you set "language" from the command line for these cases.
+language = 'fr'
+
+# There are two options for replacing |today|: either, you set today to some
+# non-false value, then it is used:
+#today = ''
+# Else, today_fmt is used as the format for a strftime call.
+#today_fmt = '%B %d, %Y'
+
+# List of patterns, relative to source directory, that match files and
+# directories to ignore when looking for source files.
+exclude_patterns = ['_build']
+
+# The reST default role (used for this markup: `text`) to use for all
+# documents.
+default_role = 'literal'
+
+# If true, '()' will be appended to :func: etc. cross-reference text.
+#add_function_parentheses = True
+
+# If true, the current module name will be prepended to all description
+# unit titles (such as .. function::).
+#add_module_names = True
+
+# If true, sectionauthor and moduleauthor directives will be shown in the
+# output. They are ignored by default.
+#show_authors = False
+
+# The name of the Pygments (syntax highlighting) style to use.
+pygments_style = 'sphinx'
+
+# A list of ignored prefixes for module index sorting.
+#modindex_common_prefix = []
+
+# If true, keep warnings as "system message" paragraphs in the built documents.
+#keep_warnings = False
+
+# If true, `todo` and `todoList` produce output, else they produce nothing.
+todo_include_todos = False
+
+
+# -- Options for HTML output ----------------------------------------------
+
+# The theme to use for HTML and HTML Help pages.  See the documentation for
+# a list of builtin themes.
+html_theme = 'alabaster'
+
+# Theme options are theme-specific and customize the look and feel of a theme
+# further.  For a list of options available for each theme, see the
+# documentation.
+#html_theme_options = {}
+
+# Add any paths that contain custom themes here, relative to this directory.
+#html_theme_path = []
+
+# The name for this set of Sphinx documents.  If None, it defaults to
+# "<project> v<release> documentation".
+#html_title = None
+
+# A shorter title for the navigation bar.  Default is the same as html_title.
+#html_short_title = None
+
+# The name of an image file (relative to this directory) to place at the top
+# of the sidebar.
+#html_logo = None
+
+# The name of an image file (relative to this directory) to use as a favicon of
+# the docs.  This file should be a Windows icon file (.ico) being 16x16 or 32x32
+# pixels large.
+#html_favicon = None
+
+# Add any paths that contain custom static files (such as style sheets) here,
+# relative to this directory. They are copied after the builtin static files,
+# so a file named "default.css" will overwrite the builtin "default.css".
+html_static_path = ['_static']
+
+# Add any extra paths that contain custom files (such as robots.txt or
+# .htaccess) here, relative to this directory. These files are copied
+# directly to the root of the documentation.
+#html_extra_path = []
+
+# If not '', a 'Last updated on:' timestamp is inserted at every page bottom,
+# using the given strftime format.
+#html_last_updated_fmt = '%b %d, %Y'
+
+# If true, SmartyPants will be used to convert quotes and dashes to
+# typographically correct entities.
+#html_use_smartypants = True
+
+# Custom sidebar templates, maps document names to template names.
+#html_sidebars = {}
+
+# Additional templates that should be rendered to pages, maps page names to
+# template names.
+#html_additional_pages = {}
+
+# If false, no module index is generated.
+#html_domain_indices = True
+
+# If false, no index is generated.
+#html_use_index = True
+
+# If true, the index is split into individual pages for each letter.
+#html_split_index = False
+
+# If true, links to the reST sources are added to the pages.
+#html_show_sourcelink = True
+
+# If true, "Created using Sphinx" is shown in the HTML footer. Default is True.
+html_show_sphinx = False
+
+# If true, "(C) Copyright ..." is shown in the HTML footer. Default is True.
+html_show_copyright = False
+
+# If true, an OpenSearch description file will be output, and all pages will
+# contain a <link> tag referring to it.  The value of this option must be the
+# base URL from which the finished HTML is served.
+#html_use_opensearch = ''
+
+# This is the file name suffix for HTML files (e.g. ".xhtml").
+#html_file_suffix = None
+
+# Language to be used for generating the HTML full-text search index.
+# Sphinx supports the following languages:
+#   'da', 'de', 'en', 'es', 'fi', 'fr', 'hu', 'it', 'ja'
+#   'nl', 'no', 'pt', 'ro', 'ru', 'sv', 'tr'
+#html_search_language = 'en'
+
+# A dictionary with options for the search language support, empty by default.
+# Now only 'ja' uses this config value
+#html_search_options = {'type': 'default'}
+
+# The name of a javascript file (relative to the configuration directory) that
+# implements a search results scorer. If empty, the default will be used.
+#html_search_scorer = 'scorer.js'
+
+# Output file base name for HTML help builder.
+htmlhelp_basename = 'Algorithmiquedoc'
+
+# -- Options for LaTeX output ---------------------------------------------
+
+latex_elements = {
+# The paper size ('letterpaper' or 'a4paper').
+'papersize': 'a4paper',
+
+# The font size ('10pt', '11pt' or '12pt').
+#'pointsize': '10pt',
+
+# Additional stuff for the LaTeX preamble.
+#'preamble': '',
+
+# Latex figure (float) alignment
+#'figure_align': 'htbp',
+}
+
+# Grouping the document tree into LaTeX files. List of tuples
+# (source start file, target name, title,
+#  author, documentclass [howto, manual, or own class]).
+latex_documents = [
+    (master_doc, 'Algorithmique.tex', u'Cours d\'algorithmique',
+     u'promotion GMSI B3', 'manual'),
+]
+
+# The name of an image file (relative to this directory) to place at the top of
+# the title page.
+latex_logo = '_static/cesi.jpg'
+
+# For "manual" documents, if this is true, then toplevel headings are parts,
+# not chapters.
+latex_use_parts = True
+
+# If true, show page references after internal links.
+#latex_show_pagerefs = False
+
+# If true, show URL addresses after external links.
+#latex_show_urls = False
+
+# Documents to append as an appendix to all manuals.
+#latex_appendices = []
+
+# If false, no module index is generated.
+#latex_domain_indices = False
+
+
+# -- Options for manual page output ---------------------------------------
+
+# One entry per manual page. List of tuples
+# (source start file, name, description, authors, manual section).
+man_pages = [
+    (master_doc, 'algorithmique', u'Algorithmique Documentation',
+     [author], 1)
+]
+
+# If true, show URL addresses after external links.
+#man_show_urls = False
+
+
+# -- Options for Texinfo output -------------------------------------------
+
+# Grouping the document tree into Texinfo files. List of tuples
+# (source start file, target name, title, author,
+#  dir menu entry, description, category)
+texinfo_documents = [
+    (master_doc, 'Algorithmique', u'Algorithmique Documentation',
+     author, 'Algorithmique', 'One line description of project.',
+     'Miscellaneous'),
+]
+
+# Documents to append as an appendix to all manuals.
+#texinfo_appendices = []
+
+# If false, no module index is generated.
+#texinfo_domain_indices = True
+
+# How to display URL addresses: 'footnote', 'no', or 'inline'.
+#texinfo_show_urls = 'footnote'
+
+# If true, do not generate a @detailmenu in the "Top" node's menu.
+#texinfo_no_detailmenu = False
+
+
+# -- Options for Epub output ----------------------------------------------
+
+# Bibliographic Dublin Core info.
+epub_title = project
+epub_author = author
+epub_publisher = author
+epub_copyright = copyright
+
+# The basename for the epub file. It defaults to the project name.
+#epub_basename = project
+
+# The HTML theme for the epub output. Since the default themes are not
+# optimized for small screen space, using the same theme for HTML and epub
+# output is usually not wise. This defaults to 'epub', a theme designed to save
+# visual space.
+#epub_theme = 'epub'
+
+# The language of the text. It defaults to the language option
+# or 'en' if the language is not set.
+#epub_language = ''
+
+# The scheme of the identifier. Typical schemes are ISBN or URL.
+#epub_scheme = ''
+
+# The unique identifier of the text. This can be a ISBN number
+# or the project homepage.
+#epub_identifier = ''
+
+# A unique identification for the text.
+#epub_uid = ''
+
+# A tuple containing the cover image and cover page html template filenames.
+#epub_cover = ()
+
+# A sequence of (type, uri, title) tuples for the guide element of content.opf.
+#epub_guide = ()
+
+# HTML files that should be inserted before the pages created by sphinx.
+# The format is a list of tuples containing the path and title.
+#epub_pre_files = []
+
+# HTML files that should be inserted after the pages created by sphinx.
+# The format is a list of tuples containing the path and title.
+#epub_post_files = []
+
+# A list of files that should not be packed into the epub file.
+epub_exclude_files = ['search.html']
+
+# The depth of the table of contents in toc.ncx.
+#epub_tocdepth = 3
+
+# Allow duplicate toc entries.
+#epub_tocdup = True
+
+# Choose between 'default' and 'includehidden'.
+#epub_tocscope = 'default'
+
+# Fix unsupported image types using the Pillow.
+#epub_fix_images = False
+
+# Scale large images.
+#epub_max_image_width = 0
+
+# How to display URL addresses: 'footnote', 'no', or 'inline'.
+#epub_show_urls = 'inline'
+
+# If false, no index is generated.
+#epub_use_index = True

algorithmique/cours/fondement.txt

@@ -0,0 +1,99 @@
+Présentation de l'art de programmer
+====================================
+
+Le processus d'abstraction
+--------------------------
+
+Débuter en programmation n'est pas une chose aisée. Aujourd'hui, la tendance est au 
+"bas niveau". Souvent, on se jette dans le grand bain :
+
+- soit en s'approchant au maximum de la machine (admin système et réseau, noyau
+  linux, langage C)
+
+- soit en faisant du dev web côté backend, ce qui ramène à une administration réseau 
+  de bas niveau (microservices, monde nodeJS/javascript, etc...)
+
+Soit on suit un cursus scolaire traditionnel qui commence souvent par une 
+explication du fonctionnement d'une machine abstraite de bas niveau, puis en 
+allant de plus en plus haut, mais étant sous-entendu qu'il faut rester connecté au 
+bas niveau (comprendre comment ça se passe derrière la scène).
+
+Dans ces deux cas, il est sous-entendu qu'on apprend plus de choses et plus 
+rapidement en mettant les mains dans le cambouis, ce qui vrai bien sûr. Mais cela 
+sous-entend qu'un développeur doit rester le nez dans le guidon, ou au moins qu'il 
+se doit d'être un expert du système dans lequel il évolue (connaissance du système 
+d'exploitation, binding avec le C, du ramasse miette (garbage collector), 
+interaction avec les différentes librairies, gestion et optimisation de la mémoire, 
+architecture par microservices, threads...)
+
+L'approche algorithmique consiste en exactement le contraire : elle commence par se 
+placer du côté de l'esprit humain et de ses capacités de compréhension et 
+d'abstraction.
+
+Le lien est fait ensuite avec le plus bas niveau grâce une implémentation effective 
+des langages à partir des paradigmes de rationalisation de la penseée (modules, 
+objects, généricité, polymorphisme paramétrique...) et d'un outil de communication 
+avec la machine qu'on appelle compilateur (dont la description est en dehors de 
+l'objectif de ce cours).
+
+La tendance générale de l'évolution des languages est de se libérer de ces 
+contraintes de bas niveau, un peu comme en sciences physiques où les lois physiques 
+dépendent de l'échelle d'en dessous (du niveau microscopique/quantique) mais qu'à 
+l'échelle du dessus, on n'a pas affaire à des effets de bas niveau (pas d'effets 
+quantiques à un niveau macroscopique en général). Ce processus d'évolution est vrai 
+aussi dans le monde de la technique informatique lui-même (modèle OSI, comment est 
+construite une trame IP, indépendances de chaque couche (transport, payload) entre 
+elles). Même la tendance système est à la virtualisation qui accentue encore la 
+tendance à s'affranchir du bas niveau (le niveau système), le séparer nettement du 
+haut niveau (le niveau applicatif).
+
+Il apparaît régulièrement de nouveaux langages. Comment s'orienter ? Quel(s) 
+langage(s) choisir pour un projet de développement ? Au delà de leurs disparités, la 
+conception et la genèse de chacun d'eux procèdent d'une motivation partagée : la 
+volonté d'abstraire.
+
+- **s'abstraire de la machine** : un langage de programmation permet de 
+  négliger l'aspect *mécanique* de l'ordinateur. On oublie le modèle du 
+  microprocesseur, jusqu'au système d'exploitation sur lequel sera exécuté
+  le programme.
+
+- **abstraire les erreurs** : Il s'agit ici de garantir la sûreté d'exécution; un 
+  programme ne doit pas se terminer brutalement ou devenir incohérent en cas d'erreur. 
+  Un des moyens pour y parvenir est le typage des programmes et la mise
+  en oeuvre d'un mécanisme d'exceptions.
+
+- **abstraire le mode opératoire** : Il s'agit de choisir une représentation, un 
+  paradigme d'implémentation qui est indépendant du domaine considéré (paradigme 
+  objet, modulaire, générique, composants...)
+
+- **abstraire les composants** : Les langages de programmation donnent la 
+  possibilité de découper une application en différents composants logiciels, plus ou 
+  moins indépendants et autonomes. La modularité permet une structuration de plus haut 
+  niveau de l'ensemble d'une application complexe. Les langages à objets constituent 
+  une autre approche de la réutilisabilité permettant la réalisation très rapide de 
+  prototypes.
+
+Détails des niveaux d'abstraction par rapport à la machine
+-----------------------------------------------------------
+
+L'extrème déploiement des langages (plusieurs milliers de langages différents)
+est dû au succès de l'ordinateur.
+
+- **niveau 0** : le langage machine. Illisible, c'est une suite d'optcode.
+  impossible de coder dans ce langage.
+
+- **niveau 1** : langage d'assemblage. Il reste très dépendant de la machine
+  et aujourd'hui il est rare d'en faire, sauf si on code un bootloader par exemple, 
+  la gestion de l'accès à la mémoire est en réel (le mode protégé n'apparaît que après).
+  Il faut gérer les ressources,le langage est très optimisé mais presque impossible 
+  à maintenir et rendre générique.  Aujourd'hui plus personne ne code en assembleur.
+  
+- **niveau 2** : langages dits de **bas niveau** : (exemple : le C, le C++)
+  indépendance par rapport à la machine, grande structuration mais très verbeux
+
+- **niveau 3** : langages dits de **haut niveau** : le raisonnement dans ces
+  langages ne dépent plus de la machine, et ils implémentent des paradigmes de
+  programmation indépendant de l'état de la mémoire de l'ordinateur,
+  ils sont indépendant même du système d'exploitation.
+
+

algorithmique/cours/index.txt

@@ -0,0 +1,30 @@
+.. Algorithmique documentation master file, created by
+   sphinx-quickstart on Thu Mar 16 16:07:00 2017.
+   You can adapt this file completely to your liking, but it should at least
+   contain the root `toctree` directive.
+
+Introduction à l'algorithmique
+================================
+
+Contents:
+
+.. toctree::
+    :maxdepth: 2
+
+    fondement
+    langage
+    modularite
+
+
+.. algorithmique
+
+
+
+
+Indices and tables
+==================
+
+* :ref:`genindex`
+* :ref:`modindex`
+* :ref:`search`
+

algorithmique/cours/langage.txt

@@ -0,0 +1,220 @@
+Les langages de programmation
+=============================
+
+Approche historique et chronologique
+-------------------------------------
+
+- début des langages vers les années 1950 (A0, Fortran(impératif),
+  Lisp(impératif et fonctionnel), Cobol)
+- années 60 : Simula (classes), CPL (compilation séparée)
+- années 70 : C (référence du langage impératif de bas niveau), Pascal
+  (procédures), Smalltalk (programmation orientée objects), Prolog
+  (programmation logique), Scheme (programmation fonctionnelle pure), Modula,
+  C++, Ada, Turbo Pascal, Common Lisp, Eiffel (programmation par contrats)
+- années 80 : ML, CAML (langages fonctionnels)
+- années 90 : Perl, Python, Ruby (languages de scripting multi-paradigmes)
+  Haskell (fonctionnel pur), Lua, Delphi, Java (orienté objet, machine
+  virtuelle), PHP (impératif, dédié au web), Erlang (fonctionnel+
+  programmation concurrente), javascript (orienté web, objets par
+  prototypage), OCaml (multi-paradigme, fortement typé, orienté sécurité,
+  programmation générique, fonctionnelle et objets, modulaire et fonctorielle)
+- 2009 : go (google, compilé, typage statique, objets par prototypage,
+  prgrammation concurrente), Rust (fondation mozilla, multiparadigme, programmation concurrente)
+
+Les langages actuellement les plus utilisés dans le monde de l'entreprise sont :
+
+- javascript/NodeJS (70% du code dans le dépôt github) mais victime de son
+  succès (chaos complet des librairies)
+- le go est de plus en plus utilisé, c'est **le** langage qui monte
+  actuellement
+- Python, Ruby, lua, autres langages de scripting (de plus en plus utilisés)
+- PHP, Java (stagnants)
+- C, C++ (de moins en moins utilisés)
+
+Approche par typologie des langages
+-----------------------------------
+
+- **A0 (1954)** : possibilité de découpage de programmes en
+  sous-programmes ;
+
+- **ALGOL (1958)** : concept de bloc de code (pas forcément nommé) et d'imbrication
+  de blocs de code ;
+
+- **C (1971)** : syntaxe claire et simple, programme fortement structuré ;
+
+- **C (1980)** : le **code objet**, qui consiste à essayer de faire fonctionner
+  un seul jeu d'instructions sur des machines différentes. Avant, le code
+  d'assemblage dépendait du processeur, donc il n'y avait pas un seul et unique
+  jeu d'instructions ;
+
+- **1980** : déploiement et succès des langages à objets ;
+
+- **1983** : turbo pascal (Borland) qui fut le tournant du C,
+  propose un IDE (Environnement de Développement Intégré).
+  aujourd'hui le turbo pascal a pratiquement disparu mais pas totalement,
+  il est soutenu par une communauté open source autour de **Lazarus** ;
+
+- **depuis les années 90** : deux grands groupes de langages. Les langages à
+  objets, et les langages fonctionnels. Les deux mondes s'interpénètrent (les
+  avancées actuelles du web, les microservices (Erlang, Haskell),
+  viennent du monde fonctionnel, le NoSQL, etc).
+  Les grandes avancées architecturales (système d'exploitation, linux, etc...)
+  viennent du monde de l'impératif.
+
+
+Approches par modèles de programmation
+--------------------------------------
+
+- **le mécanisme d'exceptions** : il est possible de rompre l'exécution normale d'un
+  programme à un endroit et de la reprendre à un autre endroit du programme prévu à
+  cet effet. Ce mécanisme permet de gérer les situations exceptionnelles.
+
+- **le paradigme impératif** : les entrées-sorties, les modifications physiques de
+  valeurs et les structures de contrôle itératives sont possibles.
+
+- **le paradigme fonctionnel** : manipule les fonctions comme étant des valeurs du
+  langage. Celles-ci peuvent être utilisées en tant que paramètres d'autres fonctions
+  ou être retournées comme résultat d'un appel de fonction.
+
+- **le paradigme objet** : La représentation du programme colle à la réalité en
+  reproduisant des entités relativement proches des objets réel. Attention, le piège
+  est de croire qu'il s'agit *du* paradigme universel puisqu'il reproduit en miroir le
+  réel. **C'est en fait un processus d'abstraction comme un autre**.
+
+Sûreté du langage, typage
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Tri par ordre de sûreté croissant :
+
+0. typage très faible (presque inexistant aujourd'hui) : 42 == "42" == 42.0...
+1. typage dynamique faible : (javascript) (possibilité de changer le prototype
+   d'un objet pendant l'éxécution du programme, c'est la fête on peut faire
+   n'importe quoi)
+2. typage dynamique fort inféré par le comportement (behavior, duck typing)
+   (python, ruby, PHP) Le contenu de la variable détermine le choix du typage
+   `var = 0 -> type int`
+3. typage statique déclaré fort (Java)
+   `int var = 0 ;` (pas mal mais super lourd, pas **agile** du tout)
+4. langages à types statiques muni d'un moteur d'inférence de types (Ocaml)
+   sûreté d'exécution, agilité, sécurité.
+
+
+La syntaxe, la lisibilité
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Importance de la lisibilité (notamment par rapport aux méthodes agiles).
+
+- courte (python)
+- verbeuse (C)
+- l'importance des mots clef du langage
+- délimiteur de phrase, de blocs (parenthèses, accolades, tabulations, blocs...)
+
+Langages compilés ou interprétés ?
+-----------------------------------
+
+- **le typage statique** : la vérification de la compatibilité entre les types des
+  paramètres formels et des paramètres d'appel est effectuée au moment de la
+  compilation du programme. Dès lors, il n'est pas nécessaire de faire ces
+  vérifications durant l'exécution du programme ce qui accroît son efficacité. En
+  outre, la vérification de type permet d'éliminer la plupart des erreurs introduites
+  par maladresse ou étourderie et contribue à la sûreté de l'exécution.
+
+- **le typage dynamique** : la vérification de la compatibilité entre les types des
+  paramètres formels et des paramètres d'appel est effectuée au moment de l'exécution
+  ou de l'appel à certaines parties de codes du programme.
+
+- **le polymorphisme paramétrique** : une fonction ou un objet qui n'explore pas la
+  totalité de la structure d'un de ses arguments accepte que celui-ci ait un type non
+  entièrement déterminé. Ce paramètre est alors dit polymorphe. Cette particularité
+  permet de développer un code générique utilisable pour des structures de données
+  différentes tant que la représentation exacte de cette structure n'a pas besoin
+  d'être connue par le code en question. L'algorithme de typage est à même de faire
+  cette distinction.
+
+- **l'inférence de types** : le programmeur n'a besoin de donner aucune information
+  de type à l'intérieur de son programme. Le langage se charge seul de déduire du code
+  le type le plus général des expressions et des déclarations qui y figurent. Cette
+  inférence est effectuée conjointement à la vérification, lors de la compilation du
+  programme.
+
+Les grands paradigmes de programmation
+---------------------------------------
+
+Le paradigme des objets
+~~~~~~~~~~~~~~~~~~~~~~~
+
+- 1962 (SIMULA) : premières notions de classes ;
+
+Pui, une dizaine d'années plus tard :
+
+- C++ : intégration des classes pour le C ;
+- turbo pascal : intégration des classes pour le pascal ;
+
+Tous les langages actuels ont intégré des traits objets mais de manière très
+différentes :
+
+- perl (1987)
+- python (1991)
+- Ruby (1993)
+
+- L'implémentation des objets en python est très proche des notions initiales de
+  classes issues du Smaltalk et présente une tentative très intéressante
+  d'unification des objets et des types depuis python 2.2 ;
+
+- Java (1995) : très grosse réussite industrielle en surfant sur la vague de la
+  programmation objet, et des machines virtuelles, mais en fait et avec le recul,
+  doté d'un support objet lourd et alambiqué.
+  Le monde Java est lourd, avec des outils consommant beaucoup de mémoire et
+  qui ne satisfont pas à la règle du KISS (Keep It Simple, Stupid) ;
+
+
+Les supports objets sont riches et variés,
+
+- objets obligatoirement construits pas des classes (Java, C++, ...)
+- objets sans définition de classes (javascript, Ocaml, go, rust)
+- langages à attributs (python)
+- langages ou le type des objets est défini par leur classe (python, ruby)
+- langages ou le type des objets est différent du type de leur classe (Ocaml)
+- objets sans classes mais construits par des prototypes (javascript)
+- construction d'objets possibles objets sans classe du tout  (Ocaml)
+- encapsulation des attributs des objets (Java, Ocaml, C++, PHP)
+- pas d'encapsulation des attributs (python, ruby, javascript...)
+
+Le paradigme impératif
+~~~~~~~~~~~~~~~~~~~~~~
+
+Un programme est une suite d'états de la mémoire de l'ordinateur,
+c'est la suite logique des machines de Turing.
+La plupart des programmeur aujourd'hui raisonnent suivant ce paradigme,
+et ont une très faible visibilité par rapport aux autres paradigmes existants.
+Seuls les programmeurs cultivés sont aujourd'hui capable de raisonner
+suivant différents paradigmes, ce sont des programmeurs chevronnés et
+cultivés.
+
+Le paradigme fonctionnel
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+La notion de fonction que possède sous une forme ou une autre la plupart des
+langages est empruntée aux mathématiques et non à l'électronique. D'une manière
+générale, les langages substituent des modèles formels aux conceptions purement
+calculatoires. Ils y gagnent en expressivité. Certains langages fondent leur
+paradigme de programmation sur l'abstraction entrée-traitement-sortie, donc sur le
+**mathème fonctionnel** et pas sur la boite noire électronique. La fonction
+mathématique apporte un niveau opératoire dans le traitement de l'information.
+
+
+Approche par fonctionnalités
+----------------------------
+
+Plusieurs domaines de l'informatique on proposé/imposé des méthodologies,
+des manières de faire. Ces modèles de programmation on fortement influencé
+en retour les langages. On reconnaît aujourd'hui :
+
+- Le modèle client-serveur
+- Le modèle de programmation concurrente (exécution de processus légers, threads) :
+- Le modèle de développement d'une application de bureau (MVC, ergonomie d'interface)
+- Le modèle de développement web (communiquer sur le réseau Internet, API
+  REST, microservices...)
+- Le modèle de programmation système et réseau
+- le modèle **Dev Ops** et les méthodes de développement virtualisés
+- les langages présentant des **fonctionnalités agiles**

algorithmique/cours/modularite.txt

@@ -0,0 +1,51 @@
+La programmation modulaire
+==========================
+
+Structuration d'un programme
+-----------------------------
+
+La réalisation d'applications importantes oblige le programmeur ou l'équipe de
+développement à se poser des questions d'organisation et de structuration.
+Aujourd'hui, on dispose de deux grands modèles d'organisation dont les avantages et les
+particularités sont distincts.
+
+La modularité
+~~~~~~~~~~~~~
+
+Les données et les traitements sont regroupés au sein d'une même entité à deux
+facettes : d'un côté le code proprement dit, de l'autre son interface. La
+communication entre modules s'effectue via leur interface. La description d'un
+type peut être masquée en n'apparaissant pas dans l'interface du module. Ces
+types de données abstraits facilitent les modifications d'implantation à
+l'intérieur d'un module sans affecter les autres modules qui s'en servent. De
+plus, les modules peuvent être paramétrés par d'autres modules augmentant
+ainsi leur réutilisabilité.
+
+Le paradigme objet
+~~~~~~~~~~~~~~~~~~
+
+Les descriptions des traitements et des données sont regroupées dans des
+entités appelées **classes**; un objet est une instance (valeur) d'une classe.
+La communication entre objets est réalisée par envoi de message, l'objet
+receveur détermine à l'exécution (liaison retardée) le traitement
+correspondant au message. En cela, la programmation objet est dirigée par
+les données. La structuration d'un programme provient des relations entre
+classes, en particulier l'héritage permet de définir une classe par extension
+d'une autre.
+
+Comparaison entre les deux paradigmes
+-------------------------------------
+
+Il y a dualité entre ces deux modèles.
+
+- On ne peut pas augmenter les composants d'un type dans un module (pas
+  d'extensibilité des données), mais on peut ajouter de nouveaux traitements
+  (extensibilité des traitements) sur ces données.
+
+- En objet, on peut ajouter des sous-classes à une classe (extensibilité des
+  données) pour traiter des nouveaux cas, mais on ne peut pas ajouter de nouveaux
+  traitements visibles de la classe ancêtre (pas d'extensibilité des traitements).
+
+**La combinaison des deux paradigmes offre de nouvelles extensibilités pour les
+traitements et les données.**
+