Livres informatiques gratuits pour noel

Sur github , victor felder a eu la bonne idée de référencer  les livres informatiques gratuits.
Le lien est ici. La partie française est là.

J'ai cherché aussi des livres gratuits sur spring-batch:

Lien ici

Et sur jenkins (lien ressource en francais ici)

Immortel COBOL : un framework MVC en COBOL

Avec le projet COBOL on Wheelchair donnez une seconde jeunesse à vos développements COBOL.

Ce projet est ici   il permet d’écrire des applications WEB en COBOL selon le modèle MVC .

Le prérequis : un serveur HTTP, un compilateur COBOL (ex: openCobol sur Linux)  ET des développeurs COBOL.
  Les parties Controleur et dispatching semblent marcher  mais la partie modèle (accès aux données) n'est pas abordée.
Il n'y pas de doute, les développeurs COBOL sont de la tribu des immortels.

Pourquoi Paypal migre ses applications de Java/J2E vers Node.js

Paypal a fait une annonce qui fait le tour du web: cet acteur majeur dans le moyen de paiement a annoncé l'abandon de Java/J2E en faveur de Node.js pour tous ses services.
Lire l'article ici.  ou ici en francais.
Cette décision est motivée par:

• La durée raccourcie du cycle de mise en production
• La durée raccourcie d'apprentissage de la filière Javascript
• Et surtout pour des raisons de coût et  de performance. 

Site Payal:(lien ici)

Sur la performance:

• Double the requests per second vs. the Java application. This is even more interesting because our initial performance results were using a single core for the node.js application compared to five cores in Java. We expect to increase this divide further.
• 35% decrease in the average response time for the same page. This resulted in the pages being served 200ms faster— something users will definitely notice.

Sur les couts:

• Built almost twice as fast with fewer people
• Written in 33% fewer lines of code
• Constructed with 40% fewer file

Les gains  d'apprentissage constaté dans la nouvelle filière est  de 1 pour 10  (1 jour pour javascript vs 10 jours pour J2E) . La pile J2E utilisée était le  framework Spring.

Paypal a mis en place une pile logicielle à base du framework Express. Et a reversé des librairies javascript servant à prendre en charge la sécurité dont

Lusca

Out-of-the-box application security. Lusca is middleware that can be deployed over Express, and configured to plug common attack vectors. When used, it will:

• Enable Cross Site Request Forgery (CSRF) headers.

• Enable Content Security Policy (CSP) headers.

• Enable X-FRAME-OPTIONS headers to help prevent Clickjacking.

• Enable Platform for Privacy Preferences Project (P3P) headers.

Lusca (lien ici) implemente la couche sécurité pour Express.

Donc: moins de ligne, moins de personnel , plus rapide et plus simple.

Installation de Jenkins; continuous integration system

Le projet phare pour faire de l’intégration continue était jusqu’à présent Hudson . Oracle par le rachat de SUN s'est retrouvé à la tête de projet opensource. Avec les conséquences suivantes: fork de Mysql , openoffice et Hudson.
Jenkins est la suite de Hudson en dehors de la sphère d'Oracle.

L'intégration continue est un ensemble de pratiques utilisées en génie logiciel consistant à vérifier à chaque modification de code source que le résultat des modifications ne produitpas de régression dans l'application développée. Bien que le concept existât auparavant^{[réf. nécessaire]}, l'intégration continue se réfère généralement à la pratique de l'extreme programming. (source wikipedia) 

L'installation de jenkins est simple: soit par le gestionnaire de paquet, soit par téléchargement de l'archive et son lancement par la commande java.
Jenkins embarque sont propre serveur web.
Aussi après son lancement par:

java -jar jenkins.war

donnera dans son navigateur : (http://locahost:8080)

http://localhost:8080

Pour un démarrage automatique par le systemV  d'unix:

 Ubuntu propose un utilitaire graphique Bootup-Manager pour gérer le démarrage des services.

Jenkins permet de lancer n’importe quel batch  en plus de sa fonction principale de construire et de tester des projets.

Jenkins est utilisable pour des projets en Java mais aussi PHP, Ruby et javascript (node.js)

Applications COBOL: Les belles anciennes

L'informatique connait actuellement un certain nombre de mutation. Les smartphones,les tablettes  le cloud, les réseaux sociaux , le NoSQL et le bigdata: des mots qui rythment les avancées technologiques. Mais on oublie vite qu'il reste des milliers de programmes COBOL comportant des millions de ligne . Sur ces programmes reposent l'ossature des traitements réalisés par les Administrations, les Banques ou les assurances. Ces applications sont un peu les oubliées de l'informatique. Elles sont portant  des belles anciennes.

3 choses à savoir au sujet de ces applications:

1 ) Il ne reste que le meilleur.... et le pire

Dans la plupart des cas  les applications restantes sont bien écrites , seuls les meilleurs programmes ont survécus , un peu comme une sélection naturelle. Un mauvais programme , mal écrit , sans évolution possible parce que trop complexe a déjà fait l'objet d'un portage vers des technologies plus modernes. Il reste le haut du panier des programmes COBOL. Hélas à coté de ces bons élèves se trouvent des programmes 'stratifiés'. Chaque évolution faisant l'objet d'un empilement supplémentaire.

2) Coût de maintenance.

Elles ont un coût d'entretien  faible car elles sont sûres  Elles ont tourné  des millions de fois avec des cas de figure inimaginables. Chaque recoin de l’application a été testé en réel. Le coût de correction d'une application COBOL est moins élevé que pour une application J2E

( 5,42 $ par ligne de code Java , tandis qu'une erreur sur Cobol ne coûte que 1,26 $)  

source: http://www.lemondeinformatique.fr/actualites/lire-erreurs-de-programmation-java-coute-plus-cher-que-cobol-46976.html

3) Lecture simplifiée de l'algorithmie des programmes COBOL 

La composition d'un programme COBOL facilite sa prise en main.

Sur 100 lignes de programmes COBOL seules 20 implémentent directement la partie métier. Les autres servent à mettre le programme en relation avec son environnent (ENVIRONMENT division ) 

ou à définir les données à traiter (DATA division). L’algorithmie est regroupée dans très peu de ligne dans la PROCEDURE division. Ce phénomène  de concentration ne se retrouve pas dans des programmes issus d'une approche objet hébergés au sein d'un framework: on assiste dans ce cas un éparpillement façon puzzle de algorithmie générale du programme.

Façon puzzle : RIP

Les coûts.  

Aussi, les coûts / risques  des anciens programmes  (legacy) viennent d'un part de l'infrastructure MAINFRAME à entretenir  (licence et matériel) et d'autre part de la perte de compétence sur la partie métier (absence de documentation générale) . 

La  génération des programmeurs COBOL va arriver à l'age de la retraite. 

Je recommande aux jeunes ingénieurs de passer par la case 'COBOL' pour booster leur carrière 

Le retour des disques vinyles

Alors que faire ?

Cette question revient souvent dans les forum comme quora.com

A la question: pourquoi les banques continuent à utiliser leurs programmes  COBOL ?

Voici une des réponses qui résume bien: 

J'ai travaillé dans l'autorité de conception technique pour Natwest Bank et Royal Bank of Scotland. Ceci est un résumé de ce que le chef de la stratégie technique m'a dit une fois:

Le montant d'argent que la banque a investi en COBOL et d'autres technologies plus anciennes est massive.

Cet immense investissement au cours des décennies a abouti à un système bancaire de base qui a des capacités qui ne sont pas reproduits par les éditeurs de progiciels. 

Personne ne sait vraiment comment l'énorme monticule de code spaghetti fonctionne réellement. Le projet de reverse engineering   serait un projet gargantuesque.

Les projets gargantuesques ne sortent jamais

Et quel serait l'avantage - le système fonctionne comme il est.

Architectures orthogonales

J'ai entendu une fois l'expression 'architectures orthogonales'  sans avoir plus de détail.
En piochant à droite et à gauche, on imagine que cette notion fait référence aux des
 architectures verticales et horizontales.

Le modèle 3tiers

On a d'un coté des modèles d'infrastructure en 'tiers' avec généralement 3 tiers:
Le serveur web , le serveur de traitement (applicatif) et le serveur de données (SGBD) .

La conception MVC

A cette spécialisation  des rôles  s'ajoute un découpage fonctionnel en couche MVC 

Le serveur applicatif met en oeuvre un ensemble de design pattern: Model Vue Contrôleur (inventé bien avant le WEB) 

Et le reste: OOP , OS

A ce mille-feuille vient s'ajouter les couches liées au développement en approche objet puis celles du système d'exploitation.

Et donc..

On se retrouve avec un empilement de module , de composant de nature et de taille hétérogène.

Or quel est l'objectif:  Offrir un service de qualité à nos utilisateurs. Ici intervient la notion de scalabilité. Comment supporter un nombre d'utilisateur plus important avec des volumes de données en hausse ?.

A chaque fois le problème est botté en touche en direction des  responsables d'infrastructure. 

Leur  seule  réponse possible est  d'augmenter le nombre de serveur pour doubler, tripler les composants. 

Mais empiler des briques hétérogènes fragilise la stabilité de l'ensemble. C'est coûteux pour un rendement marginal décroissant.  Car cet empilement ne donne pas un rendement d’échelle linéaire. 

Il faut trouver des systèmes pour partager des sessions serveurs , gérer des caches à tous les niveaux, des répartiteurs etc.  bref le prix à payer est élevé. 

La scalabilité horizontale consiste à augmenter le nombre de machine. La scalabilité verticale vise à augmenter la puissance unitaire des machines.  L'orthogonalité cherche à combiner les deux approches en par une simplification des architectures.

Vers des architectures pus simples et ... moins coûteuses.

La première règle à mettre à oeuvre est de réaliser des applications avec des architectures simples avec moins de couche.

Règle 1: simplifier les couches d'abstraction: chaque abstraction coûte et ajoute de la  complexité  

  

Avez vous besoin de faire une application métier de gestion ou un site de publication ?

Si la réponse est 'une application métier' , vous n'avez pas besoin d'un serveur web complet pour votre application.  

Votre choix doit se tourner vers des serveurs applicatifs à gestion d’événement non bloquants et asynchrone  (Non-bloking I/O event loops) comme Node.js pour javascript , VertX pour Java ou eventmachine pour ruby.

Et des mico-frameworks comme Express ou Sinatra. 

Dans ces technologies , le développeur  travaille directement son cœur de métier: la mise à disposition de ressources. Il n'est plus tributaire de la configuration lourde d'un serveur HTTP.

Un process en attente sur un serveur =  gaspillage de ressource = les serveurs vous font les poches.  

Règle 2: Réfléchir en terme de conteneur autonome. 

Votre application doit être l'assemblage de briques identiques autonomes. Ces briques ne doivent pas gérer ou partager des sessions. Celles ci sont prises en charge par le client (REST: les requêtes sont autonomes

Ce qui implique aussi que chaque conteneur accèdes à des données dans son contexte. 

Aussi un conteneur embarque : une couche HTTP, l'application métier et le backend de stockage.

Comment passer d'une architecture 'classique' à une architecture moderne. 

• Tout d'abord la partie applicative:

• Puis la partie frontale :

Pour accéder aux conteneur, il est possible de placer en frontend le serveur NGINX. Ici ,il n'est pas utilisé comme un serveur web mais comme un reverse-proxy avec des fonctionnalités de répartition de charge.

• La partie backend ou stockage:

L'usage d'une base NoSQL viendra compléter le dispositif et rendra chaque 'nœud' autonome les uns par rapport aux autres.

•  La partie SSO  peut elle aussi être implémentée sur chaque nœud: 

  

Ici , il n'est plus question de SSO préemptif ou coopératif: on est dans un mode de micro-SSO 

Pour aller plus loin.

L'idée générale est d'obtenir des boites identiques autonomes un peu comme ceci :

Permettant empilements à la fois verticaux et horizontaux = Orthogonaux  = des constructions solides.

Le site Colbert 2.0

Le ministère du Redressement productif a mis en ligne sont outil Colbert 2.0 destiné à calculer les gains de relocalisation. Quel est l'architecture du site ?:

- Le moteur est en PHP sur un serveur Apache.
- Utilisation de jquery pour faciliter les échanges avec  l'utilisateur
- Utilisation du framework 'Bootstrap' pour la mise en page et le design.

Bootstrap est une collection de javascript , de feuille de style (CSS) qui permet de réaliser des sites web bénéficiant des dernières avancées ergonomiques. Bootstrap permet de gèrer des affichages sur mobiles ou tablette : (responsive design) , le projet est porté par les équipes de twitter.