Java pour les nuls, ou Tecka va tout planter Options

Merci Maître

Merde j'ai séché le cours mais c'est bon maintenant j'ai recopié
Comme mon camarade de classe.
Merci maître

Comme l'a indiqué appleseed, les livres de O'Reilly sont vraiment hors-normes. Là je lis "Design Patterns" dans la série "Tête la première", ça se lit comme un roman et c'est plein d'humour à la Monty Python, c'est beaucoup plus rigolo que le spectacle ou le film d'un comique français (bon en même temps, les deux auteurs sont des utilisateurs de Mac, ça aide pour apprendre l'humour rigolo et non vulgaire visiblement).

Suppression du message pour non respect de la charte.

Ce message a été modifié par Darknight670 - 3 Apr 2008, 13:39.

Ici on n'aime pas les étrangers pirates, étranger pirate (le photoco-pillage tue le livre)

Ce message a été modifié par atarxerxes - 1 Apr 2008, 21:50.

Pas la peine d'être agressif De plus je possède la plupart des livres parce que lire sur un écran de Mac tout un livre c'est vraiment la misère...

Sinon pour le Java:
http://java.developpez.com/cours/
http://www.jmdoudoux.fr/accueil_java.htm

Pour le Cocoa la Doc d'Apple est très bien faites je trouve ( je commence a essayer a l'apprendre avec celle ci...) mais considère que vous avez deja les bases minimum en C

Pas la peine d'être agressif De plus je possède la plupart des livres parce que lire sur un écran de Mac tout un livre c'est vraiment la misère...

Je ne suis pas agressif mais dans la charte du forum il y a

- Il est interdit d'aider, d'encourager, de promouvoir le piratage en ces pages

or il est illégal de proposer des livres en pdf ou autres gratuitement quand on n'en possède pas les droits ou qu'ils ne sont pas libres

Pas la peine d'être agressif De plus je possède la plupart des livres parce que lire sur un écran de Mac tout un livre c'est vraiment la misère...

Je ne suis pas agressif mais dans la charte du forum il y a

- Il est interdit d'aider, d'encourager, de promouvoir le piratage en ces pages

or il est illégal de proposer des livres en pdf ou autres gratuitement quand on n'en possède pas les droits ou qu'ils ne sont pas libres

C'est vrai j'avais tort et je m'en excuse.

Ok, tu peux faire un bisou à Atar maintenant (tu vas voir l'effet magique du bisou à moustaches)

MMMMMMMMMMHHHHHHHHH

Sinon il y a des livres gratuits sur java

- penser en java ou en anglais
- java 2

@+

[HS] igoogle c'est vraiment bien [/HS]

Ce message a été modifié par appleseed - 4 Apr 2008, 14:21.

Pour la suite des leçons, vous devrez attendre début Mai (j'aurai quelques congés à prendre à cette période). Là entre Mario Kart, le boulot, Mario Kart, les sorties, Mario Kart, le temps de dodo et Mario Kart j'ai pas trop le temps.

Leçon 2 : le MVC/l'architecture N-tiers

Quand on développe un nouveau logiciel, il y a un but et deux logiques s'affrontent pour y parvenir :
- le but est de faire un logiciel qui correspond au cahier des charges initial
- la première logique est de développer le logiciel le plus rapidement possible pour augmenter la rentabilité du produit
- la seconde logique est de penser à la maintenabilité et l'évolutivité du logiciel ("un logiciel qui ne change plus est un logiciel mort", un logiciel dont personne se sert quoi)

Suivant la taille du projet et les circonstances on peut déplacer le curseur entre ces deux logiques à différents endroits.
Pour simplifier pour les petits projets ça sera plus proche de la première logique.
Pour les projets à plusieurs dizaines de jours de développement et dont la durée de vie cible est de 4 ou 5 ans, on favorisera la seconde logique.

Développer en suivant la première logique consiste grosso modo à faire un ou plusieurs gros "scripts" de code (comme du BASIC par exemple). On appelle cela du développement spaghetti.

A contrario, la seconde logique impose un développement plus structuré, pas forcément plus lisible de manière globale en première approche mais plus sûrement modifiable au final. Pour se structurer on peut suivre sa propre intuition mais sans garantie de résultat, ou plus simplement suivre les exemples des personnes intelligentes qui se sont réunies pour réfléchir ensemble et en tirer des modèles fiables.

Dans les années 80, avec l'apparition des applications avec interface graphique un tel modèle est apparu : le MVC (Modèle-Vue-Contrôleur). Je ne vais réexpliquer ce qui est dans l'article de wikipédia, mais en gros on distingue donc trois rôles, trois sortes de travail dans une application et on essaie de répartir correctement ces rôles : un bouton sera créé/réglé dans une partie du code consacrée à la Vue, les calculs métier seront dans le Modèle,...
C'est un modèle efficace pour les applications traditionnelles ou client/serveur (iTunes par exemple, le serveur étant l'iTS dans ce cas). Mais il est assez peu efficace pour les applications Internet/Intranet (qui s'exécutent dans un navigateur web en gros) sauf à prendre des modes de travail un peu plus compliqué (comme GWT).

Vu que ces applications ont quand même plus le vent en poupe que les applications traditionnelles grâce à leurs qualités (déploiement, maintenance,...) et malgré leurs défauts certains (interface limitée par le HTML, plus lent,...), un nouveau modèle s'est dégagé : l'architecture N-tiers (3-tiers dans sa forme la plus utilisée).
Tout d'abord, non ! "tiers" ne signifie par "1/3" mais interlocuteur à l'anglaise, il n'y a donc pas forcément 3 tiers .
Pour résumer le modèle, au lieu d'avoir trois interlocuteurs qui dialoguent librement entre eux comme dans le MVC, on a ici une répartition stricte en couches : 3 couches, chacune ne pouvant échanger des informations qu'avec la couche au-dessus ou en dessous d'elle. Le dialogue est unidirectionnel : couche 1 vers couche 2 ou couche 2 vers couche 1 (en pratique ça se traduit dans le code par :
- couche 1 vers couche 2 : la couche 1 appelle une fonction de la couche 2 en lui passant certains paramètres : la méthode choisie et les paramètres constituent les informations apportées par la couche 1 à la couche 2 dans son dialogue
- couche 2 vers couche 1 : la méthode de couche 2 renvoie une valeur qui est l'information qui est amenée par la couche 2 à la couche 1

Les trois couches sont (de la plus proche de l'utilisateur de l'application à la plus lointaine) : présentation, métier, données persistantes.

Les dialogues dans l'application sont :
- présentation <- métier : récupération des données métiers nécessaires à la construction des pages web de l'application
- client <- présentation : génération des pages web
- client -> présentation : clic sur un lien/validation d'un formulaire/ouverture d'une requête Javascript/...
- présentation -> métier : transfert des informations de l'utilisateur après validation et mise en forme de celles-ci
- métier -> données : après transformation/traitement, passage des informations à sauver
- données -> système de persistance (fichiers, base de données,...) : écriture des données
- données <- système de persistance : chargement des données sauvées précédemment
- métier <- données : après transformation des données brutes en objets métier, passage de ceux-ci

Dans une application Struts (sans framework définie de gestion de la persistance), cela se traduit par exemple par :
- des pages JSP, des classes Action, des classes Form : couche présentation
- des classes Manager, des classes d'objets métier (Business Objects) (par exemple un article dans notre application de gestion des stocks) : couche métier
- des classes DAO, des classes DTO/Value Objects : couche données


La prochaine leçon, on commencera par établir le cahier des charges de notre application de gestion de stocks.

Ce message a été modifié par atarxerxes - 17 May 2008, 11:08.

aaaaaaaah enfin la suite.
Merci mon lapin

Intéressant, étrange (pour un pur jus assembleur/pascal/c comme moi) mais intéressant. Merci atarxerxes, vivement la suite.

uand on développe un nouveau logiciel, il y a un but et deux logiques s'affrontent pour y parvenir :
- le but est de faire un logiciel qui correspond au cahier des charges initial
- la première logique est de développer le logiciel le plus rapidement possible pour augmenter la rentabilité du produit
- la seconde logique est de penser à la maintenabilité et l'évolutivité du logiciel ("un logiciel qui ne change plus est un logiciel mort", un logiciel dont personne se sert quoi)

Ah tient ! ça me rappelle le boulot. Avec l'AS3 kiff kiff.

Leçon 3 : le cahiers des charges

Notre but est de réaliser une petite application de gestion d'un stock d'articles quelconques.
Les actions possibles doivent être :
- listing de l'ensemble des types d'article du stock
- ajout d'un nouveau type d'article
- ajout d'articles pour un type d'article donné
- retrait (pour vente ou autre raison) d'articles pour un type d'article donné
NB : on distingue les types d'articles (par exemple les clous CL-2145 d'un article (un clou CL-2145 donné que l'on peut tenir dans sa main)). Dans notre application on va supposer qu'on s'occupe de petits articles de ce type et on va uniquement s'intéresser à suivre l'évolution du nombre de types d'articles. Pour des types d'articles plus conséquents, on aurait pu avoir à s'intéresser aux articles (par exemple pour des télés assez chères, on aurait sans doute voulu suivre précisément chaque télé du stock, avec un numéro d'inventaire unique pour chacune pour des raisons évidentes (détecter les vols, gérer les garanties,...).
On ne permettra pas de modifier un type d'article, ce sera à l'utilisateur d'en créer un nouveau si le type d'article évolue (en effet c'est logique car les articles de ce type que l'on a déjà en stock ne vont pas évoluer d'un coup de baguette magique car le fournisseur a modifié son mode de travail).
On choisit de ne pas gérer les prix de ventes ou d'achats sachant qu'ils sont évolutifs dans le temps ou peuvent avoir des règles de gestion ponctuelles (remise exceptionnelle,...). Le prix serait sans doute stocké (si on voulait le gérer) dans une table historique des opérations sur les types d'articles (exemple : on garderait la trace de l'ajout de 45 articles au prix unitaire d'achat de 1,25€, on garderait la trace de la vente de 12 articles au PU HT de vente de 7,95€,...). Pour le moment on peut se limiter à la gestion des quantités d'articles uniquement.
On pourrait aussi avoir une gestion plus poussée des fournisseurs (avec leurs propres informations à part) mais on va se contenter de ne juste garder que leurs noms.

Les informations que l'on veut stocker sur le type d'article :
- identifiant unique : long
- code : string
- nom : string
- date d'entrée au catalogue : date
- fournisseur : string
- quantité en stock : long
- date de dernière modification de la quantité : date

A côté de chaque champ, le type de donnée probable que l'on utilisera.
Pourquoi distinguer un identifiant unique et un code? Le code sera utile pour les employés du magasin, il est sans doute aisément mémorisable par les utilisateurs, mais c'est une string. En règle générale c'est plus sûr d'avoir pour identifiant interne unique un nombre (affecté par le système). Cela dit on aurait pu effectivement utiliser ce code comme identifiant unique.

Pour modéliser notre type d'article, on va créer une classe TypeArticleBean (on rajoute le terme Bean à la fin du nom car on va respecter les conventions des beans Java).
Notre application va donc se contenter de jongler avec des TypeArticleBean lorsqu'on lui demandera d'effectuer une opération (listing, ajout,...).

Prochaine leçon :
- on commencera par installer Eclipse Europa
- on créera notre projet dans Eclipse
- on créera notre classe TypeArticleBean
- on créera une application de test de cette classe

oups j'ai séché le cours .........
Il faut se remettre au boulot j'ai rien fait depuis 1 mois presque

Atar, petite question à la sauvette car je n'ai pas encore pris le temps de m'intéresser à la question :

Y a t'il moyen, en java, d'assembler des images (de très grande résolution) sans bouffer trop de RAM ? Par exemple, 4 images à assembler en une seule en carré.

Je bricole actuellement sur des fractales avec deux potes et on se posait la question (parce qu'il s'agit vraiment de très grandes images).

Je donnerai plus de détails quand mon petit projet avancera, mais pour le moment les 2 Go de RAM de mon MBP ont de la peine à suivre

Il faudrait voir le code exact.
"Assembler" ça veut dire quoi en Java? Créer une Image à partir des quatres autres?
Tu utilises des Image, BufferedImage, ou autres?

Il faudrait voir peut-être dans la doc de Java2D s'il n'y pas un truc là-dessus : api spec / tutorial.

J'ai jamais eu à réfléchir à ces problématiques mais on doit sans doute trouver sur Internet soit dans les stratégies de programmation des jeux, soit des logiciels de traitement d'images (satellite par exemple) des exemples de stratégies.
Enfin ça dépend de ce que tu veux faire exactement : si c'est ouvrir 4 grosses images pour les assembler en 1 seule pour créer le fichier d'une très grosse image, il faut peut-être passer par une autre stratégie (par exemple créer le fichier de la grosse image à la bonne taille mais vide, puis ouvrir chaque image l'une après l'autre pour l'écrire dans le fichier de la grosse image).

D'un point de vue plus pratique, j'imagine que tu as déjà augmenté les paramètres de mémoire de ta JVM.

Ce message a été modifié par atarxerxes - 17 Jun 2008, 06:23.

En effet en ce qui concerne la mémoire (avec les 64 mo alloués par défaut je suis limité à des "BufferedImages" d'une taille d'environ 6000 pixels par 6000.).

Je vais regarder si c'est faisable en se servant des flux, mais pour le moment je bricole encore une autre partie du programme.

Pour les curieux, il s'agit de repartir le calcul d'une fractale (de Mandelbrot) sur plusieurs postes en découpant l'image a calculer en sous-parties. Le but étant d'obtenir la résolution la plus haute possible afin de pouvoir s'amuser (oui oui, s'amuser) à zoomer très loin dans l'image.

Actuellement, sur mon MacBook pro, je suis limité à une image carrée d'environ 24000 pixels de largeur.

Je me suis fait ce petit "exercice" parce que j'adore les fractales et que je m'intéresse également au calcul distribué (je gère toute la répartition des tâches, mais je serais également curieux de savoir comment faire via xGrid). Je précise car on m'a déjà conseillé plusieurs fois de faire une application qui recalcule uniquement la zone que l'on souhaite afficher ; perso je préfère plutôt faire mouliner les ordis de ma coloc le plus longtemps possible, c'est plus rigolo

Quand on aura de belles images j'en montrerai quelques unes ici, et si jamais, la Fractale en elle-même n'est vraiment pas difficile à calculer !

Peut-être du nouveau bientôt !

aaaaaaaaah la reprise des cours après les vacances