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.

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

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

Je ne suis pas agressif mais dans la charte du forum il y a 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]

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.

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.

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.

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

Pour cette rentrée, on va s'éloigner un peu de l'exemple (légèrement) entamé pour réaliser une petite application qui brasse pas mal de technologies différentes.
En plus cette application sera utile (enfin j'espère au moins pour Heimdal !).

Le but sera de mettre en place une application qui produit un flux RSS (ou Atom, on verra par la suite, en tout cas un flux de syndication). Ce flux permettra de suivre l'actualité des jeux vidéos (sorties,...) (ça permettra de remplacer le calendrier que j'avais commencé et que j'ai la flemme de continuer ).

L'application sera assez simple :
- une partie administrative pour faire du CRUD sur nos actualités
- une partie publique qui fournira le flux de syndication


D'un point de vue technologie, on aura a priori :
- une base MySQL pour stocker nos données
- notre application J2EE (partie publique offerte par une servlet, partie administrative par des pages JSP)
- un serveur Tomcat pour faire tourner notre application
- la génération et la manipulation d'un fichier XML (avec XSLT)
- une page html de test d'affichage du flux par Ajax (pour ceux qui ne veulent pas passer par un logiciel dédié)

Cool

Ça c´est une bonne nouvelle J´ai tendance à tout mélanger avec les css, les php, les javascripts...

Enfin, là je disais que l'application te serait utile surtout parce que tu étais le seul à consulter mon calendrier

Bonne idée, je vais suivre ça, je connais encore mal XML/XSLT!

Cette fois je vais essayer de finir l'application exemple AVANT de faire les "cours" pour arriver à finaliser quelque chose (elle est à 25%-30% actuellement, j'espère la finir ce week end)

L'application qu'on va réaliser en pas à pas est grosso modo fonctionnelle (même s'il y a encore des trucs à améliorer, surtout niveau présentation).
Elle peut être visualisée ici : http://atarxerxes3.hd.free.fr:8080/vg_actus/ (présentation testée uniquement sous Safari, il peut rester des trucs louches sous Firefox, et IE j'en parle même pas).

Premier article en guise de pré-requis prévu dans la journée (si j'arrive à ne pas lancer FIFA aujourd'hui, sinon dans la semaine) : installation et configuration de mysql/tomcat/eclipse.

Tiens, ça m'intéresse de savoir comment coder un servlet, c'est différent en quoi d'un(e) applet ? (Dans le code en fait, dans la pratique je vois très bien).

Pourquoi tu veux coder un cervelet ? Ok vous savez où me trouver.

Vive le C (ce que je fais en cours).

- applet = application à part entière (c'est une application Java standard avec quelques conventions et limitations à observer)
- servlet = juste une classe qui sert à écrire une réponse HTTP à une requête HTTP (post, get,...). C'est juste une classe tout bête avec certaines fonctions bien définies à implémenter

Sommaire évolutif et approximatif :

1. les installations
2. spécifications de l'application
3. création de la base et des tables
4. création du projet Eclipse, mise en place du log
5. mise en place de l'authentification Tomcat
6. connexion Java-MySQL
7. récupérations d'informations dans la base
8. génération du flux XML des actualités
9. transformation et affichage du flux XML
10. construction du modèle des pages HTML
11. écriture des requêtes de modification/ajout/suppression
12. écriture des pages de modification/ajout/suppression
13. prototype + scriptaculous : le javascript fiable, facile et spectaculaire
14. saisie facile des dates
15. validation des données saisies
16. écriture de la servlet publique
17. génération du flux Atom

Première étape : les installations (explications minimales, ne pas hésiter à se manifester si quelque chose bloque !)

- Installation de MySQL : installation de MySQL sous Léopard (on peut aussi en profiter pour activer php sous Apache2, ça mange pas de pain).
Les réglages par défaut sont :
- utilisateur root (pas de mot de passe) sur la machine localhost en tant qu'administrateur

- Installation de MySQL Tools : http://dev.mysql.com/downloads/gui-tools/5.0.html. Cela installe deux applications :
- MySQL Administrator (sert à créer les utilisateurs, les tables,... de manière graphique)
- MySQL Query Browser (sert à créer les utilisateurs, les tables,... et les données par requête SQL)

- Tomcat : http://tomcat.apache.org/download-55.cgi (le package Core en 5.5.27 suffira).
Il suffit de le dézipper dans un répertoire (par exemple dans /Applications).
A priori les scripts sh ne sont pas exécutables par défaut après dézippage : un petit coup de "chmod +x *.sh" dans le répertoire bin de tomcat répare cela.
Si on veut lancer tomcat à la main, cela se fait par un "./startup.sh" (respectivement "shutdown.sh" pour l'éteindre) après s'être déplacé dans le répertoire bin de tomcat (si des permissions denied apparaissent, un petit coup de sudo chown sur le répertoire (et en particulier sur le contenu du répertoire de logs) devrait remettre les choses d'aplomb) .
Pour vérifier que le serveur se lance correctement, il suffit de lancer un navigateur à l'adresse "http://localhost:8080/" (normalement c'est le port par défaut, sinon il suffit d'aller dans le fichier conf/server.xml à la ligne 77 environ voir le port utilisé).
On va aussi en profiter pour ouvrir le fichier conf/tomcat-users.xml et pour supprimer les rôles différents de tomcat, ainsi que les utilisateurs qu'on remplace par notre propre utilisateur (à vous de définir son nom et son mot de passe).
Par exemple :


- Eclipse Ganymede : Eclipse Ganymede Mac OS X J2EE, à dézipper et placer dans /Applications par exemple.
On peut vérifier en double-cliquant sur l'application qu'elle se lance correctement.
On peut ne profiter pour rajouter notre serveur Tomcat dans l'onglet Serveur (clic-droit dans l'onglet -> New -> Server -> Tomcat 5.5, indiquer le répertoire).

Du coup (en s'assurant qu'il est éteint) on peut lancer et éteindre notre serveur tomcat depuis Eclipse (clic-droit Start, respectivement Stop).

Dans l'onglet Console, on récupère même les messages qui s'affichent dans le fichier de log Catalina.out.

Applet: application chez le client en general avec interface graphique. Indication via un tag dans la page HTML


Exemple d'applet




Servlet: application chez le serveur, sortie page HTML ou XML ... lancement par le serveur.

Exemple de servlet

A noter qu'une servlet peut produire vraiment n'importe quoi, et pas seulement du contenu "textuel".
Exemples courants d'utilisation obligée d'une servlet où le contenu est du binaire :
- une servlet d'affichage : on lui passe un nom d'image par exemple, et on reçoit le flux de l'image en réponse (exemple : <img src="http://monsite.com/maSuperServlet?img=toto.jpg"/>)
- un échange d'objets Java sérialisés (par exemple un client qui reçoit des objets Java métier d'un serveur)

Okay ! Donc c'est bien le serveur qui exécute des "scripts" java qu'on a placé puis appelé sur celui-ci ? Je vais ressortir mon livre sur Java, ces implémentations côté serveur m'intéressent bigrement...

En fait Java sur un serveur tomcat c'est un peu comme php sur un Apache sur lequel php est activé.
Une différence technique : Apache détecte qu'il doit lancer php.exe d'après l'extension des url en général, alors que les serveurs J2EE sont eux-mêmes des applications Java (en fait on n'a qu'une seule grosse application Java qui est le serveur et suivant les URLs demandées cet application appelle certaines de nos classes (essentiellement des servlets ou des pages JSP)).

Sommaire évolutif et approximatif :

1. les installations
2. spécifications de l'application
3. création de la base et des tables
4. création du projet Eclipse, mise en place du log
5. mise en place de l'authentification Tomcat
6. connexion Java-MySQL
7. récupérations d'informations dans la base
8. génération du flux XML des actualités
9. transformation et affichage du flux XML
10. construction du modèle des pages HTML
11. écriture des requêtes de modification/ajout/suppression
12. écriture des pages de modification/ajout/suppression
13. prototype + scriptaculous : le javascript fiable, facile et spectaculaire
14. saisie facile des dates
15. validation des données saisies
16. écriture de la servlet publique
17. génération du flux Atom

Seconde étape : les spécifications

Il faut savoir ce qu'on veut que notre application puisse faire.
On va partir sur :
- un jeu vidéo a un titre unique, un éditeur, une description, une liste de liens de previews, une liste de liens de tests
- il peut sortir sur un seul support (Wii par exemple) ou sur plusieurs (X360, PS3,...). Chaque version peut avoir quelques spécificités (par exemple utilisation de la Wii Balance Board sur Wii, inferior version sur PS3,... )
- il peut sortir dans un seul territoire (les territoires sont : Japon, USA, Europe). La sortie sur un territoire est datée. Elle peut avoir quelques spécificités (par exemple le sang enlevé sur No More Heroes en Europe mais pas aux USA).

Au niveau fonctionnalités de l'application on voudra (au moins dans un premier temps) :
- partie administration : liste des jeux, création/modification d'un jeu, suppression d'un jeu. La modification/création d'un jeu permet la planification de la sortie (en plus bien sûr de la modification des caractéristiques du jeu et de la spécification de ses supports)
- partie publique : juste un flux Atom regroupant les différents jeux récemment modifiés (on pourra limiter le nombre de jours à récupérer afin de ne pas faire sauter le serveur quand il sera bien plein dans quelques années)

Au niveau technique :
- base MySQL pour stocker les données
- serveur tomcat
- application J2EE standard
- partie administration : pilotage par pages JSP, protection light en utilisant les mécanismes incorporés à tomcat
- partie publique : servlet qui produit le flux XML

[moitié HS]C´est nickel, ton flux rss d´actualité des jeux [/moitié HS]

En fait c'est pas si HS que ça, je vais utiliser ce flux pour indiquer les jeux qui ont l'air intéressants, ça ira plus vite que de passer par un calendrier iCal (par contre il faut que je vois si je peux améliorer l'organisation des infos dans le flux, un tri par date de sortie européenne serait pas mal quand même)

Parmi les améliorations dans les tuyaux :
- le support indiqué en plus dans le titre (déjà fait, juste à redéployer l'application)
- insertion des liens vers les focus et les tests Gamekult (ou autre) (bientôt dispo)
- des images pour les supports (petits gifs des consoles) et les formats (petits gifs des drapeaux) (d'ici 10 jours)
- éventuellement, insertion de liens vers les screenshots Gamekult (ou autre) (ou alors présentation de ceux-ci en utilisant une adaptation de ce code PHP/JS : ImageFlow) (à plus longue échéance)
-...

Pour Tomcat et Eclipse, pas de problèmes; par contre MySQL Manager n´arrive pas à établir de connexion (il trouve le serveur localhost quand je le ping) En laissant la touche command appuyée il m´affiche skip et je vois d´autres options mais je n´arrive pas à lancer le serveur (tomcat fonctionne avec http://localhost:8080/). C´est bon j´ai trouvé (oublié de télécharger MySQL, quel noob cet Heimdal )

Effectivement j'ai peut-être oublié de dire qu'il faut démarrer le serveur mysql par la commande : dans le répertoire /usr/local/mysql/bin Ca marche mieux?

Sinon :
Fonctionnalités disponibles !

Non quand tu installes MySQL (du site Mac4ever), tu as un paquet MySQLStartupitem qui te démarre MySQL automatiquement Tout fonctionne maintenant

En tout cas sur mon mini, c'était déjà tellement le merdier au niveau des installs que j'ai du le démarrer à la main, MyStartupitem n'y arrivait pas.

Ca te dit quoi quand tu le démarres à la main?

J´ai configuré MySQL Administrator comme suit: Préférences, dans le dossier connexions appuyé sur le +, connexion name: localhost, user: root, password: laisser vide, hostname: localhost, port:8080. Eclipse trouve Tomcat et je peux lancer le serveur à partir de là (menu contextuel, start).

Alors attention :
- une seule application/processus peut écouter sur un port donné (sinon c'est comme deux personnes qui liraient le même courrier : seul le premier arrivé lit la lettre)
- 8080 est le port de Tomcat
- le port par défaut de MySQL est le 3306

Essaie avec ce port plutôt : 3306 sur localhost

C´est corrigé