Tuesday, June 27, 2017

Peut-on apprendre la programmation "en quelques jours"


Developpez.com - Accueil

    Forums Autre rubrique

Peut-on apprendre la programmation "en quelques jours"
Comme le proposent tant de livres ? Combien de temps faut-il au minimum ?
Le 06/09/2011, par Gordon Fowler, Expert éminent sénior
Peter Norvig est un développeur qui a fait une expérience amusante. Il a effectué une recherche sur Amazon avec les mots « apprendre en quelques jours », puis « en quelques heures ». Il a alors constaté que 90% des résultats concernaient l'informatique.

Deux conclusions lui sont alors venues à l'esprit : soit le développement devient de plus en plus populaire, soit le développement est un chose très simple à apprendre.

En fait, Peter Norvig opte pour une troisième option qu'il reprend du livre « How To Design Programs » : « Mal programmer est facile, n'importe quel idiot peut le faire, même les Nuls (NDR : allusion à la série "Pour les Nuls" des Editions First) ».

La vérité, selon lui, est que n'importe quel champs d'activité exige une dizaine d'année de pratique avant de pouvoir s'en revendiquer expert. Qu'il s'agisse d'échecs, de piano, de sport ou de sciences, rien ne peut se faire en 7 jours, 24 heures ou 3 mois.

Pour lui, le développement ne fait pas exception.

Qu'il faille 10 ans, 10.000 heures ou une vie entière (en fonction des références qu'il cite), il faut du temps pour devenir un « vrai développeur ». Et Peter Norvig doute que les compétences nécessaires puissent se trouver dans des livres.

Il ne nie pas l'intérêt de les lire pour compléter son savoir (les bons, tout du moins), mais sa recette pour devenir développeur ne repose pas sur eux. Celle-ci mélange l'amusement et la passion, l'échange avec les autres programmeurs, le travail, le travail et encore le travail, la connaissance du hardware (dans développement informatique il y a le mot « informatique ») et l'implication dans les évolutions des standards.

A cela il ajoute des études dans le domaine (pour rentrer plus facilement dans le milieu) et l'apprentissage d'au moins une douzaine de langages différents.

Tout ce qui ne se trouve pas, en résumé, dans des livres « en 7 jours ».

« Allez y, achetez ce livre sur Java, il vous sera certainement utile », conclue-t-il. « Mais il ne changera pas votre vie ou votre expertise sur le sujet, que ce soit en 24 heures, jours ou mois ».

Et de rêver d'une librairie remplie de livres dont les titres seraient « Apprenez à programmer en plus de 10 ans » (ou « Learning Perl the Hard Way », PDF sous licence GNU Free Documentation) ?

Source : "Teach Yourself Programming in Ten Years" de Peter Norvig

Et vous ?

D'après votre expérience, combien de temps cela prend-il pour devenir développeur ?
Quelle place tiennent les livres dans votre formation ?
Qu'est-il possible d’apprendre en programmation “en quelques heures”, comme le proposent tant de livres ?
Discussion forum

Poster une réponse

Avatar de diallomad diallomad - Membre averti
le 06/09/2011 à 14:01
Citation Envoyé par Gordon Fowler  Voir le message
[B][SIZE="4"]Qu'est-il possible d’apprendre en programmation “en quelques heures”, comme le proposent tant de livres ?

Je ne suis pas développeur, je ne suis qu'un étudiant mais à mon avis c'est impossible d'apprendre la programmation en quelques heures sauf s'il agit uniquement du fameux "Hello World"
Avatar de brulain brulain - Membre régulier
le 06/09/2011 à 14:03
que la connaissance naît de l'expérience, tout le reste n'étant qu'information.

Si tant est que je le veuille, je peux peut-être 'apprendre' les règles du foot ou du basket en quelques heures ; mais jamais je ne parviendrais à atteindre le niveau des meilleurs joueurs.

Tout apprentissage demande plus ou moins de temps, en fonction de nos aptitudes et de notre motivation.

Le côté sympa de la chose, c'est que cela ne peut pas s'acheter.
Avatar de Grimly_old Grimly_old - Membre averti
le 06/09/2011 à 14:18
D'après votre expérience, combien de temps cela prend-il pour devenir développeur ?
Quelle place tiennent les livres dans votre formation ?
Qu'est-il possible d’apprendre en programmation “en quelques heures”, comme le proposent tant de livres ?

2 ans approximativement sont nécessaires pour apprendre à programmer
Les livres n'ont que peu d'importance, un prof a bien plus d'efficacité. Programmer n'est pas une connaissance. Un livre aura donc moins d'impact à mon avis.
On peux apprendre à programmer avec un langage en quelques heures ... si on a de l'expérience dans d'autres langages qui y ressemble !
Avatar de helio500 helio500 - Membre régulier
le 06/09/2011 à 14:19
Je pense qu'il a raison dans la totalité,
concernant les livres ils sont bien adaptés pour les débutants mais sont beaucoup trop superficiels pour quelqu'un qui connait déjà le sujet.
Si on veut se perfectionner il va falloir acquérir de l'expérience en développant.
C'est très facile de tester son niveau dans un langage, prendre un livre du style "apprendre en 21 jours..." et venir sur les forums developpez.com et lire des sujets que présentent certaines personnes (qui ne font pas parties de la section débutants) et on se rendra vite compte qu'on n'a pas un gros niveau...
Avatar de Freem Freem - Membre émérite
le 06/09/2011 à 14:21
Je suis globalement d'accord avec lui.
Cela fait 8 ou 9 ans que j'ai tapé mes 1ères lignes de code (ahh QBasic...) depuis je n'ai cessé d'apprendre.
Je n'ai que très peu utilisé de livres (d'ailleurs, c'est marrant, le seul que j'aie acheté, je l'ai trouvé très mauvais: "le C++ pour les nuls"... sic...) presque uniquement des ressources trouvées sur le net, et LA DOC des langages (gros remerciements au passage a dvp ou j'ai trouvé la plupart des ressources de qualité) et des heures a coder des trucs qui ne servent a presque rien si ce n'est assouvir une question que je me pose a un moment donné.
Il n'empêche que je ne me considère toujours pas bon, parce que je manque d'expérience professionnelle.

Sur le fait qu'il faille connaître une douzaine de langages, par contre, je ne le rejoins pas... Je ne suis même pas sûr d'en connaître 12 de nom!
Voyons voir ça:
basic, pascal, java, C/C++, asm, python, perl, ruby, smalltalk, brainfuck (niark), php, c#, ADA, powerbuilder,windev ,SQL... ?
Bon, il y a toujours les versions évoluées de certains d'entre eux: delphi pour pascal, vb pour basic, mais au fond, c'est pas un peu les mêmes, pour la même raison que l'on dis C/C++ souvent, et pas C et C++?

Sincèrement, j'ai fait le tour de tous ceux qui me viennent à l'esprit, et il n'y en a que 16! (je sais qu'il y en a d'autres, évidemment, mais ils me viennent pas a l'esprit)

D'ailleurs, apprendre la programmation, est-ce vraiment apprendre un langage?
Ce n'est pas plutôt développer une logique (algorithmique) que l'on peut appliquer à un outil (langage)?
Savoir utiliser les outils de dev (système de contrôle de version, pour ne citer que ça) n'est pas non plus négligeables, idem pour les méthodes (agile, par exemple) et ce sont des choses que je n'ai jamais eu la chance de voir en cours...

[edit]
au autre point que je note de plus en plus, c'est que les gens confondent langage et framework!
J'ai déjà entendu "je suis un dev .NET" alors que le gars ne connaît que le C#, et même pas à fond...
De même, en BTS, on nous enseignait le C++ sauce MS ou QT, on utilisait CString ou QString, jamais ou nous a parlé de std::string...

Savoir programmer, c'est savoir apprendre et se remettre en question avant tout pour moi, et même les nombreuses (a l'échelle de ma vie, hein) années pendant lesquelles j'ai appris en autodidacte ne me font pas prétendre être programmeur, au contraire: plus le temps passe, plus je suis humble.
Avatar de tbarry tbarry - Membre du Club
le 06/09/2011 à 14:25
je crois que être développeur( je ne parle pas de juste pouvoir écrire des codes[..]) demande beaucoup de temps d'apprentissage et d'exercice,
mais pour un développeur confirmé je crois qu'il peux parfaite envisager d'apprendre un langage de programmation en quelques jours. Donc si ces livres dont vous faite allusion parle "d'apprendre un langage en quelques jours", on ne peux pas nier complètement le concept.
Avatar de Jbx 2.0b Jbx 2.0b - Membre expérimenté
le 06/09/2011 à 14:27
Même si quelques heures ou quelques jours ne suffisent de toute façon pas pour apprendre à développer, le temps d'apprentissage dépend malgré tout fortement du langage concerné.

Si j'ai pu avaler le développement Labview en quelques jours seulement (avec beaucoup d'antécédents sur divers langages qui m'ont largement facilité la tache...), après maintenant plus de 10 ans de langage C++ je continue à en découvrir certaines subtilités. Et si ces subtilités peuvent paraître futiles pour un développeur débutant, c'est pourtant ce qui ferra au final la différence sur la qualité du code produit.

Après il y a savoir programmer (à savoir réaliser un petit logiciel capable d'automatiser quelques tâches, une macro par exemple) et savoir concevoir une application complexe, avec sa phase d’architecture et de conception.
Si le premier cas peut éventuellement être appris en quelques heures, le second peut prendre des années pour être totalement maitrisé.
Avatar de missdevil666 missdevil666 - Membre à l'essai
le 06/09/2011 à 14:48
Apprendre un langage met beaucoup de temps (pour l'instant je ne suis que à 4 ans d'expérience dans les langages web html-php-javascript-jquery-sql) .

Je sors d'une formation où il y avait des apprentis et des "juste étudiant". je peux vous dire qu'un "juste étudiant" ne sait pas grand chose et ne cherche pas à apprendre par lui-même (hors passionné).

Développer reste gratter et rechercher des solutions, faire des phases de test de ses applications.

Il reste vrai qu'un livre ne permet pas d'apprendre en quelques jours un langage. Mais il permet d'avoir de petites bases après à nous de les approfondir....

De toute façon, il faut être passionné pour faire ce métier....
Avatar de tomlev tomlev - Rédacteur/Modérateur
le 06/09/2011 à 15:00
Le lien vers la source ne marche pas... l'article d'origine est ici. [corrigé]

Et dans le même esprit, je viens de lire ça :
Become a Good Programmer in Six Really Hard Steps
(il fait d'ailleurs référence à l'article de Peter Norvig)
Avatar de lucideluciole lucideluciole - Membre habitué
le 06/09/2011 à 15:12
Il y a une différence entre apprendre un langage de programmation et apprendre à programmer. C'est beaucoup plus difficile d'apprendre à bien programmer...
Poster une réponse

Copyright © 2000-2017 - www.developpez.com
En utilisant ce site, vous acceptez l'utilisation de cookies permettant de vous proposer des contenus et des services adaptés à vos centres d'intérêts -

Thursday, June 15, 2017


Using WITH (NOLOCK) SQL

 

http://sqlserverplanet.com/tsql/using-with-nolock

Client-serveur

https://fr.wikipedia.org/wiki/Client-serveur

L'environnement client-serveur désigne un mode de communication à travers un réseau entre plusieurs programmes : l'un, qualifié de client, envoie des requêtes ; l'autre ou les autres, qualifiés de serveurs, attendent les requêtes des clients et y répondent. Par extension, le client désigne également l'ordinateur ou la machine virtuelle sur lequel est exécuté le logiciel client, et le serveur, l'ordinateur ou la machine virtuelle sur lequel est exécuté le logiciel serveur.
En général, les serveurs sont des ordinateurs dédiés au logiciel serveur qu'ils abritent, et dotés de capacités supérieures à celles des ordinateurs personnels en ce qui concerne la puissance de calcul, les entrées-sorties et les connexions réseau. Les clients sont souvent des ordinateurs personnels ou des appareils individuels (téléphone, tablette), mais pas systématiquement. Un serveur peut répondre aux requêtes d'un grand nombre de clients.
Il existe une grande variété de logiciels serveurs et de logiciels clients en fonction des besoins à servir : un serveur Web publie des pages Web demandées par des navigateurs Web ; un serveur de messagerie électronique envoie du courriel à des clients de messagerie ; un serveur de fichiers permet de partager des fichiers sur un réseau ; un serveur de base de données permet de récupérer des données stockées dans une base de données, etc.
Caractéristiques d'un programme serveur :
  • il attend une connexion entrante sur un ou plusieurs ports réseaux locaux ;
  • à la connexion d'un client sur le port en écoute, il ouvre un socket local au système d'exploitation ;
  • à la suite de la connexion, le processus serveur communique avec le client suivant le protocole prévu par la couche application du modèle OSI.
Caractéristiques d'un programme client :
  • il établit la connexion au serveur à destination d'un ou plusieurs ports réseaux ;
  • lorsque la connexion est acceptée par le serveur, il communique comme le prévoit la couche application du modèle OSI.
Le client et le serveur doivent bien sûr utiliser le même protocole de communication au niveau de la couche transport du modèle OSI. On parle souvent d'un service pour désigner la fonctionnalité offerte par un processus serveur.

Sommaire

Ordinateur central

Article détaillé : Ordinateur central.
Avant que n'apparaisse l'environnement client-serveur, les réseaux informatiques étaient configurés autour d'un ordinateur central (mainframe en anglais) auquel étaient connectés des terminaux passifs (écran adjoint d'un clavier sans unité centrale). Tous les utilisateurs étaient alors connectés sur la même unité centrale.
L'ordinateur central n'affichaient que du texte à l'écran sans graphisme (pas de bouton, pas de fenêtre). Il était spécialisé dans la gestion d'informations de masse auquel il pouvait appliquer des instructions simples (addition, soustraction, etc.) mais avec une grande vélocité. Ainsi, plusieurs milliers de personnes pouvaient travailler sur cette unité centrale sans ralentissement.
Aujourd'hui, les anciens terminaux passifs ont été remplacés par des émulations logicielles installées sur des ordinateurs personnels.
Pour pallier le manque de graphisme, différentes solutions existent dont l'intégration de l'ordinateur central dans une architecture à deux, trois ou N niveaux, en laissant à d'autres la fourniture d'une interface homme-machine.
Cette architecture est déployée sur le MVS d'IBM mais aussi sur des serveurs sous Unix, Linux, etc.
Avantages :
  1. Gestion des données et des traitements centralisée.
  2. Maintenance matériel minime.
  3. Grande vélocité sur des grands volumes de données et de traitements.
Inconvénients :
  1. interface homme-machine minimaliste.
  2. Utilisation de langages de programmation anciens.
  3. Calcul scientifique complexe impossible.

Environnement client-serveur

Exemple d'architecture client-serveur : deux clients font leurs requêtes à un serveur via Internet.
L'organisation d'un environnement client-serveur diffère selon le type d'architecture du réseau et le type de client1.

Types d'architecture

Architecture pair à pair

Article détaillé : Pair à pair.
Une architecture pair à pair (peer-to-peer ou P2P en anglais) est un environnement client-serveur où chaque programme connecté est susceptible de jouer tour à tour le rôle de client et celui de serveur.

Architecture à deux niveaux

Une architecture à deux niveaux ou une architecture deux tiers (two-tier architecture en anglais) est un environnement client-serveur où le client demande une ressource au serveur qui la fournit à partir de ses propres ressources.

Architecture à trois niveaux

Article détaillé : Architecture trois tiers.
Une architecture à trois niveaux ou une architecture trois tiers (three-tier architecture en anglais) ajoute un niveau supplémentaire à l'architecture à 2 niveaux, permettant de spécialiser les serveurs dans une tâche précise, ce qui donne un avantage de flexibilité, de sécurité et de performance :
  • un client qui demande une ressource via une interface utilisateur (généralement un navigateur web) chargée de la présentation de la ressource ;
  • un serveur d'application (appelé middleware) qui fournit la ressource, mais en faisant appel aux ressources d'un autre serveur ;
  • un serveur de données qui fournit au serveur d'application les ressources requises pour répondre au client.

Architecture à N niveaux

Une architecture à N niveaux ou architecture N tiers (N-tier architecture en anglais) ajoute encore des niveaux supplémentaires à l'architecture à 3 niveaux, permettant de spécialiser les serveurs davantage.

Types de client

Client léger

Article détaillé : Client léger.
Un client léger est une application où le traitement des requêtes du client (applications Web n'utilisant pas ou peu de JavaScript côté client, terminaux Terminal Services, Secure Shell, Apple Remote Desktop, Citrix XenApp, TeamViewer, etc.) est entièrement effectué par le serveur, le client recevant les réponses « toutes faites ».

Client lourd

Article détaillé : Client lourd.
Un client lourd est une application où le traitement des requêtes du client (applications de bureau, applications mobile) est partagé entre le serveur et le client.

Client riche

Article détaillé : Client riche.
Un client riche est une application où le traitement des requêtes du client (applications Web utilisant beaucoup de JavaScript côté client) est effectué majoritairement par le serveur, le client recevant les réponses « semi-finies » et les finalisant. C'est un client léger plus évolué permettant de mettre en œuvre des fonctionnalités comparables à celles d'un client lourd.

Comparaison des architectures centralisées et distribuées

Avantages des architectures centralisées

  • Toutes les données sont centralisées sur un seul serveur, physique ou virtuel, ce qui simplifie les contrôles de sécurité, l'administration, la mise à jour des données et des logiciels.
  • La complexité du traitement et la puissance de calculs sont à la charge du ou des serveurs, les utilisateurs utilisant simplement un client léger sur un ordinateur terminal qui peut être simplifié au maximum.
  • Recherche d'information : les serveurs étant centralisés, cette architecture est particulièrement adaptée et véloce pour retrouver et comparer de vastes quantités d'informations (moteur de recherche sur le Web), par rapport à l'architecture distribuée beaucoup plus lente, à l'image de Freenet.

Inconvénients des architectures centralisées

  • Si trop de clients veulent communiquer avec le serveur au même moment, ce dernier risque de ne pas supporter la charge (alors que les architectures distribuées fonctionnent mieux en ajoutant de nouveaux participants).
  • Si le serveur n'est plus disponible, plus aucun des clients ne fonctionne (les architectures distribuées continuent à fonctionner, même si plusieurs participants quittent le réseau).
  • Les coûts de mise en place et de maintenance peuvent être élevés.
  • En aucun cas les clients ne peuvent communiquer entre eux, entrainant une asymétrie de l'information au profit des serveurs.

Exemples

  • La consultation de pages sur un site Web fonctionne sur une architecture client-serveur. Un internaute connecté au réseau via son ordinateur et un navigateur Web est le client, le serveur est constitué par le ou les ordinateurs contenant les applications qui fournissent les pages demandées. C'est le protocole de communication HTTP ou XML socket qui est utilisé.
  • Les courriels sont envoyés et reçus par des clients et gérés par un serveur de messagerie. C'est le protocole de communication SMTP, POP ou IMAP qui est utilisé.
  • Le système X Window fonctionne sur une architecture client-serveur. En général le client (une application graphique, xeyes par exemple) tourne sur la même machine que le serveur mais peut être aussi bien lancé sur un autre ordinateur faisant partie du réseau.

Notes

  1. Tout sur les systèmes d'information, Jean François Pillou, Dunod 1996

Voir aussi