configurer l'auto mount vbox

1- configurer 'dossier partager'  dans la configuration de la VM
1 bis - sudo apt-get install build-essential linux-headers-$(uname -r)
2- dans configuration, ajouter le CD ISO de guestAddition
3- monter le cdrom mount /media/cdrom
4- aller dans ce répertoire et executer VBoxLinux....run
5- Ajouter les users dans le group vboxsf
  - useradd -G root vboxsf
6- Ajouter vboxsf dans le fichier /etc/modules
7- ajouter la ligne suivante dans /etc/fstab
/[nom montage]          /[chemin repertoire]  vboxsf      defaults,rw,uid=1000,gid=1000   0  0
8- rebooter et tester ...

configurer le network/interfaces

J'oublie  toujours la configuration ...
# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug eth0
iface eth0 inet dhcp

auto eth1
iface eth1 inet static
address 192.168.56.111
netmask 255.255.255.0
network 192.168.56.0
broadcast 192.168.56.255

maintenant plus qu a faire un  un xc/xv !

Qu'est ce qu'il se passe dans la tête d'un CTO ?

Bonjour à tous,

Cela fait un bail que je n'ai pas écrit un article sur mon blog. Et je vous propose d'aborder le monde des startups et spécifiquement de la relation entre le porteur de projet (CEO) et le futur CTO, dans le cadre d’une collaboration passionnante.

Je voudrais au travers de cet article aider les futures CTO et CEO, à mieux se comprendre, se préparer à leur rencontre sous un angle que je maitrise bien :

Qu'est ce qu'il se passe dans la tête d'un CTO ?

Le future CTO se situe dans le bon côté, c'est à dire là où les très nombreux porteurs de projet se battent pour s’accaparer les peu de ressources techniques disponibles. Le rapport de force est tellement fort que certains CEO se forment à la programmation pour palier à la dure loi de la concurrence.

Avant de commencer, il faut préciser que le focus se porte sur les CEO qui n’ont pas encore levé de l’argent. En effet,   la levée de fond est plus contraignante que la recherche d’un CTO. Et avec une levé de fond, il est plus simple de trouver son CTO, si on ne l’a pas déjà …

Je vais donc traiter de différents aspects qui sont :

1-      Montage d’un dossier

2-      L’affinité entre un projet et le CTO

3-      La sagesse et l’honnêteté

4-      Le produit en lui-même

5-      Le temps, la contrainte principale

6-      Les startups sur un nuage

LE DOSSIER

L'analogie entre la recherche d’un CTO avec celle d'un appartement pour un jeune au milieu de Paris est intéressante et pertinente.  Donc, le future CEO se doit de préparer un dossier en béton, sans faille ! Et quand on parle de dossier, cela suppose le dossier papier. En effet, la qualité de ce dernier démontre le travail fournit par le porteur de projet. Lorsqu’on m’a sollicité pour une projet, on ne m’a jamais présenté un dossier, et cela me laisse vraiment perplexe quant au sérieux de le personne…

Voici ci-dessous les principaux points sur lesquels il faut répondre :

1-      Constitution de la société

L’étape de la cherche du CTO suppose que la société soit déjà créée, avec le compte bancaire et KBis associés. Ainsi, le future CEO est déjà prêt pour faire la répartition des parts, et s’est débarrassé de la paperasse. Il est étrange de s’apercevoir que beaucoup de porteur de projet n’ont pas encore créé leur startup au sens juridique.

2-      Le business plan

C'est l'un des documents principaux pour le CTO. S'il est cohérent et bien ficelé, alors il donnera de la visibilité pour le CTO, et l'aidera à mesurer les risques, par rapport au travail fournir pour la livraison du produit. Beaucoup d’ateliers ou de tutoriels existent pour rédiger ce genre de document.

3-      Le cahier des charges

Il est impossible de faire une description du produit final car il évolue en fonction du feelback des utilisateurs et il est en général enrichi. Cependant pour la V1, il est tout à fait possible de réunir un ensemble de fonctionnalités qui ensemble créée le killer feature et qui rend le produit et le positionnement de la startup intéressant. Enfin, si le CTO est bon, le CEO obtiendra le produit qui a aura été définit dans le CDC.

Sous le terme cahier des charges 3 aspects sont très importants :

a-      le design : faire un PSD, c'est 3-5 jours de travail pour un graphiste. C'est un peu d'argent, mais c'est rien par rapport à la phase du développement. Un CTO, n'est pas un graphiste et ce n'est pas son métier. Si le PSD est prêt, le CTO n'a plus qu'à l’intégrer, et cela fait gagner du temps.

b-       Définissez au mieux l'environnement du business. En effet, ce point permet simplement de déterminer l'architecture technique et logiciel ainsi que les contraintes sous-jacentes. Par exemple, dans le case study de 'mon produit va révolutionner les réseaux sociaux en Chine... ', on peut en déduire l'environnement dans lequel le produit fonctionnera :

a.       la gestion du million d'utilisateurs.

b.      sur performer la recherche de l'information de notre réseau.

c.       le contenu éditorial est faible.

d.      l'information disponible appartient aux utilisateurs...

e.      Il faut que cela fonctionne sur IE7-IE8 ...

A partir de ces points, l’architecture est définie dans les termes suivants :

f.        Il doit être scalable (plusieurs serveurs derrière un loadbalancer),

g.       une redondance des données,

h.      probablement une DB noSQL,

i.         l'impossibilité de mettre en place un proxy cache ...

Bref, un joli bordel pour le future CTO...

c-       Faire un cahier des charges fonctionnel. Si le CEO est capable de rédiger un CDC, alors cela montre parfaitement que le produit a été réfléchit (même si elle ne correspondra pas au produit final), point par point, bouton par bouton ... c’est-à-dire de manière très précis. Par conséquent, le CTO n'a plus qu'à définir le CDCT (cahier des charges techniques) et réaliser le produit. De mon point de vu, méthodes Agiles sont des méthodologies inappropriées dans le développement informatique en général. La rédaction d'un CDC possède 2 vertus importantes :

a-      se poser le temps nécessaire pour définir un bon produit, le meilleur produit

b-      quantifier la masse de travail à fournir et déterminer une deadline raisonnable (et cela est primordial pour une startup qui vie à crédit ...)

4-      Toutes informations du future CEO (Diplôme, certificat, CV , Bulletin de paie ...). De la même manière, le CTO doit avoir la même démarche, pour plus de transparence. Au premier abord, cela peut vraiment paraitre exagéré, mais il faut savoir que monter une boite avec un inconnu (même s’il y a un très bon feeling), est extrêmement risqué. Une startup, c'est 99% de galères, vaut mieux donc s'assurer que son partenaire ait les reins solides et idem pour le CTO. Avoir une personne qui a fait ses preuves dans son domaine est réellement rassurant. De plus, il faut savoir que le parcourt du porteur de projet permet d'évaluer la pertinence du projet. Une personne qui a travaillé 15 ans dans la communication, a plus de crédits si son projet concerne son domaine, que moi même qui veut ouvrir une chaine de clubs de Yoga.  Deux types de profiles CEO intéressants se semblent être pertinents parmi la tendance générales. Il y a les jeunes d’Hec, et ceux qui connaissent leur domaines d’activité depuis longtemps.

5-      Toutes informations attestant la participation (financière ou autre) d'acteurs dans le projet. Cela peut être des comptes rendu, des échanges de mails, des attestations, des documents administratifs ... Je reviendrai ultérieurement sur ce point.

L'affinité du projet avec le CTO.

Minimiser le risque et la pertinence d'un dossier ne doit pas être le seul facteur pour choisir le projet. Le CEO et CTO vont collaborer durant plusieurs années pour accoucher dans la douleur un produit, et si le produit (ou le domaine d’activité) n'intéresse pas (ou peu) le CTO, il y a alors un réel risque d'abandon de projet de la part du CTO. Malheureusement, les abandons sont très fréquents.

Le domaine d’activité ou le produit en lui-même doit permettre de susciter la curiosité du CTO en dehors des aspects purement techniques et financiers, voir même l’envie d’apprendre un nouveau métier, de rencontrer les acteurs économiques...

Etre humble et honnête face à son partenaire.

Il y a quelques mois, j'ai rencontré un porteur de projet qui voulait améliorer la notoriété de grands groupes en vendant une prestation au département communication. Même si théoriquement l'opération est viable et intéressante, je me suis permis de lui dire que les départements de communication sont les plus mal lotis, est qu'ils n'ont pas de budget pour ce genre d'opération (en gros pour être cash, il ne trouvera jamais de client).

A vrai dire, je ne sais pas si j'ai raison ou pas, mais je sais que dans une précédente expérience, un gérant d'une startup, n'a jamais trouvé de clients pour mettre en place ce type d'opération (peut être qu'il manquait d'expérience malgré son âge). Mais dans ce cas là, il faut avoir un réseau très qualifié, et que ce n'est pas à la portée de tous. Bref, au fil de la discussion, j'ai été considéré comme un simple développeur qui ne connait rien au business.

Au travers de cet exemple, 2 points sont intéressants à analyser :

a-      L'expérience de 2 personnes qui provient de mondes différents ne peut pas créer une réelle synergie par le respect des champs d'action de chacun. En effet, son collaborateur peut apporter un éclairage pertinent sur certains points dans la compréhension et sa vision de certaines problématiques. Les exemples se situent dans la reformulation du problème par son partenaire, qui n'hésite pas à titiller les faiblesses de raisonnement.

b-      Un projet ne peut se construire que si chacun fait l'effort écouter l'autre. Ce qui veut dire in fine que le projet appartient au CEO et au CTO ! Ce sont par des exemples/contre exemples et arguments/ contre arguments que le produit et le business model s'affinent. Dans le domaine technique, les développeurs/ lead développeurs / architectes qui me sollicitent pour mettre en place de nouvelles technos/ nouveaux langages, nouveaux processus de développement. Ce type de démarche est une très bonne chose car il est possible de remettre en cause des arbitrages qui aujourd’hui ne sont plus forcément pertinentes. Cependant rares sont les propositions qui sont finalement acceptées et mise en place. Pourquoi ? La réponse est simple, il faut démontrer par A+B, que la technologie est meilleure que ce qui est mise en place. Et pour qualifié la notion de 'meilleur', il faut prendre en compte (la performance, la robustesse, la maintenabilité, l'affinité du langage auprès des développeurs en interne et externe ...) Bref, il faut écrire un livre blanc, et produire un énorme travail de fond, pour qualifier la réelle pertinence d'une technologie et éventuellement l’adoptée. Dans cette situation, le fait d’être l'avocat du diable permet de sélectionner les meilleurs choix pour le projet.

L'honnêteté n’a pas encore été abordée et pourtant, elle est une qualité essentielle pour le CTO et CEO. On a tous droit à l'erreur, voir la succession d'erreurs en cascade. Par contre, la malhonnêteté même si elle se porte sur un aspect insignifiant, possède le vers destructeur de casser la confiance à jamais.

Le produit n'est pas un jouet ...

Au fil de discussion sur une possible collaboration, le CTO peut avoir l'impression que le porteur de projet n'attend qu'une chose : le produit. D'un côté c'est normal, car il doit le vendre ou le viabiliser, le monétiser... Cependant, le CTO ressent une étrange impression, cette impression que le porteur ne sera pas quoi en faire. Je rencontre quelques CTO dans les meetup, qui me font part de leur exaspérations de voir leur CEO, ne pas faire les efforts nécessaires dans son domaine. Et en général, les CEO se plaignent de la mauvaise qualité du produit, et évoque cette raison pour justifier la déroute du projet. Bref, c'est le début d'un divorce ...

De mon point de vue, ce sentiment étrange provient du manque de lucidité de la part du CEO. En effet, ces derniers sont doués pour vendre un concept, mais peu sont capable d'expliquer une stratégie commercial/marketing pour viabiliser le projet à court terme. Car finalement, si le CTO livre une version du produit et s'occupe des problématiques techniques, le CEO se doit de réussir le projet au niveau financier et commercial.

La course contre la montre, tic-tac ...

Dans un projet, il faut partir du principe que l'on peut compter uniquement que sur soi même. Qui dit soi même veut dire uniquement les associés de la startup.

Si un investisseur possède des parts dans la startup, alors, on peut compter sur lui, même s'il a décidé de ne plus mettre un rond, son aide peut se matérialiser par l'ouverture de son réseau par exemple ou sur d’autre forme.

Donc en considérant que les CEO ont en général un capital limité (un fond propre), ces derniers doivent faire le nécessaire pour commercialiser le produit avec les moyens du bord, ou maintenir une croissance constante et élevée.

Côté CTO, ce dernier doit tout mettre en œuvre pour que les coûts de développement soit les plus faibles, tout en restant robuste.

Par conséquent, les marges de manœuvres sont généralement faibles pour pondre un produit rapidement et le rendre rapidement commercial. De ce que j'observe, le meilleur couple (CEO/CTO) est composé de personnes matures, c’est-à-dire que la maturité d’une personne n'est pas proportionnelle avec son âge, mais plutôt avec sa capacité à connaitre et maitriser les moyens dont il dispose pour arriver à ses fins.

Ainsi, un développeur connaitra sera capable de déterminer la meilleur infra et architecture logiciel ainsi que les technos associées pour développer le produit. Idem pour le CEO au niveau marketing.

Au vu du contexte exposé, le temps est compté pour réussir et les marges de manœuvres sont faibles. Cependant, le succès tient en un déclic, et pour être plus précis à une succession d’améliorations minimes, permettant un décollage de l’activité. En réalité, c’est une décision (en générale anodine) qui viabilise d’un coup l’activité de la startup. Cette décision sur le business peut autant provenir d'une idée du CEO que du celle CTO, mais le succès provient du travail acharné de chacun !

Le rêve n'est pas la réalité.

Dans la section I.5, je parlais de la nécessiter de présenter, si c'est possible des documents attestant la participation d'acteurs, ou de partenaires. Alors pourquoi ? Parce que malheureusement un CEO, pour draguer un CTO, il lui vend du rêve et que un CTO a une approche pragmatique du fait de la nature de son travail. Finalement, le mieux est de lui présenter des éléments tangibles.

De nombreuses personnes se prennent pour Steeve ou Markus, et s’exclament qu’ils connaissent le directeur machin de mac do ou que mon oncle est le directeur truc d’Orange ... De plus il faut savoir qu'une rencontre débouche en générale sur pas grand chose, et surtout qu'une rencontre sur 500 mène éventuellement sur une quelque chose de concret. Accompagner ses associés pour vendre un projet à un partenaire/future associé, participer à une levée de fond sont des tâches difficiles à réaliser, et il faut être acharné pour obtenir de résultats intéressants. Il y a nulle besoin d’ajouter de la fioriture pour être crédible aux yeux des autres.

Conclusion

Si t’es donc un CTO, alors tu dois pouvoir :

-          Lire un bon gros dossier bien fournit

-          Choisir un CEO d’expérience et qui a fait ses preuves.

-          Avoir un bon feeling avec le CEO

-          Aimer le projet et le domaine d’activité.

-          Etre respectueux en vers l’autre.

-          Ne pas être considéré uniquement comme un développeur

-          Ne pas écouter les bobards

-          Se donner à 200% pour trouver le déclic

Meetup Railo ! 19 juin 2012

Nous avons le plaisir de vous inviter pour le Meetup Activ Browser du mardi 19 juin 2012 à 18h30 à Boulogne-Billancourt dédié à Railo 4 avec la présence exceptionnelle de Gert Franz, CEO de The Railo Company. 

Inscription obligatoire sur http://railo.eventbrite.com. Attention, nombre de places limité !

Ce Meetup s’adresse particulièrement aux décideurs qui pourront apprécier la pérennité et la pertinence de choisir CFML comme language de développement mais aussi aux développeurs web, php, Java, Ruby, .net… qui pourront se rendre compte du temps qu’ils pourront économiser en utilisant Railo !

• Railo, un moteur CFML Open Source mature

Le développement d’applications critiques basées sur des technologies web n’a jamais été ausi intense. À l’heure où nos utilisateurs demandent encore et toujours une ergonomie plus aboutie pour une meilleure productivité, les décideurs font face à ce casse-tête de créer les meilleures applications possible sans extension de budget… CFML est pour nous une solution pour apporter une rapidité de développement exceptionnelle côté serveur et ainsi augmenter la part des budgets pour l’interface utilisateur.

CFML, que l’on peut qualifier de framework J2E, a aujourd’hui un haut niveau de maturité : développement orienté objet, ORM, différents frameworks MVC comme MachII, FW/1 ou ColdBox, sécurité, RESTful… Cette technologique s’adresse à tous les développeurs web, PHP Java ou Microsoft .net. Le langage est appréhendable facilement par des débutants mais propose aussi tous les mécanismes qui raviront les experts (objets, exceptions, closure…).

La communauté dont nous faisons partie est aussi l’une des communautés les plus attachées et les plus actives au monde. 

L’Open Source CFML a de beaux jours devant lui… et Railo Server qui est un moteur CFML Open Source très performant.

Alors rejoignez-nous à 18h30 le mardi 19 juin au restaurant Les Loges 137, avenue Jean-Baptiste Clément à Boulogne-Billancourt. Inscription obligatoire sur http://railo.eventbrite.com. Attention, nombre de places limité !

Le système de classe sous Extjs 4.0

pour la version 4.0, Extjs a bénéficié d'un grand travail de refactoring de toutes ses bibliothèques et d'être conforme aux nouvelles normes web, à savoir HTML 5 et CSS 3, et se base sur un nouveau système de classe. Cette nouvelle architecture est derrière presque toutes les classes écrite pour Extjs 4.X, et par conséquent, il est important de bien comporendre tout ce système avant de commencer à coder.

Ce tutoriel permet aux developpeurs de créer ou d'étendre les classes existantes de Extjs 4.x. Il est divisé en 4 sections:

• Section I: "Aperçu" explique les besoins pour un système de classe robuste


• Section II: "Convention de nommage" traite les bonnes pratiques de nommage des classes methods propriétés, variables et fichiers.


• Section III: "Maitrise" Fournit des exemples détaillés de code étape par étape


• Section IV: "Gestion des erreurs et deboggage" donne des conseil utiles sur comment les supprimer avec les exceptions

I. Apperçu

Extjs 4.0 est composé de plus de 300 classes et il est utilisé par une communauté de plus de 200 000 developpeurs à travers le monde avec chacun sa manière de coder. Le gros challenge est de fournir un socle commun d'une architecture du framework:

• simple à appréhender et à le maitriser


• rapide à développer, facile à debogguer, et rapide à déployer


• bien organiser, extensible et maintenable

Javascript est un langage "orienté protopype", et non orienté objet comme c'est le cas pour PHP. Par sa nature, l'une de ses plus puissantes fonctionnalités est la FLEXIBILITE. Il peut en effet effectuer le même travail, mais de différentes manières, sur différents style de codage et de techniques. Sans une structure unifiée, un code javascript devient rapidement difficile à comprendre, maintenable et réutilisable.

La programmation basées sur les classes restent aujourd'hui le modèle le plus populaire auprès des développeurs. Les langages orientés objets exigent habituellement un très fort typage, doit fournir une encapsulation, et emploie des conventions standard de codage. La plupart des développeurs adhèrent à la plupart de ces principes, écrivent un code le plus prévisible possible, et le rends extensible et scalable le plus possible au fil du temps. Cependant, Ils(les langages Orienté Objets) ne possède pas les capacités dynamiques d'execution comme c'est le cas du Javascript.

Chaque approche à ses avantages et ses inconvénients, mais nous pouvons en tirer du meilleurs de ses 2 approche tout en masquant les inconvénients ? La réponse est oui et nous allons implémenter la solution sur Extjs 4.

II. Conventions de nommage

En utilisant les conventions de nommage au travers de votre code pour les classes, namespaces, et fichiers, vous aideront à garder votre code organisé, structuré, et lisible.

1) Les classes

Les nom des classes peuvent contenir uniquement des caractères alphanumériques. Les nombres sont autorisés mais déconseillés dans la plupart des cas, à moins qu'ils appartiennent à des termes techniques.ne pas utiliser les caractères underscore, tirets ou tout autre caractères non alphanumérique, par exemple:

• MyCompany.useful_util.Debug_Toolbar est déconseillé


• MyCompany.util.Base64 est acceptable

Les noms des classes doivent être regroupé dans des paquets proprement nommés en utilisant la notation "objet" du javascript, le point '.'. Au minimum, il devrait y avoir un unique espace de nom suivi par le nom de la classe. Par exemple:

MyCompany.data.CoolProxy

MyCompany.Application

Les nom des espace de haut niveau ainsi que les noms des classes doivent employer la notation Camel. Par exemple:

MyCompany.form.action.AutoLoad

Attention : Les classes qui ne sont pas distribué par Sencha, ne doivent jamais utiliser le nom d'espace de haut niveau "Ext".

Les acronymes doivent ainsi être suivi de la convention Camellisté comme ci dessous. Par exemple:

• Ext.data.JsonProxy instead of Ext.data.JSONProxy


• MyCompany.util.HtmlParser instead of MyCompary.parser.HTMLParser


• MyCompany.server.Http instead of MyCompany.server.HTTP

2) Les fichier sources

Le nom des classes correspondent directement aux chemins du fichier dans lequel il y est enregistré. la conséquence est qu'il doit y avoir une seule classe par fichier. Par exemple:

• Ext.util.Observable est placé dans chemin/de/la/source/Ext/util/Observable.js


• Ext.form.action.Submit est enregistré dans chemin/de/la/source/Ext/form/action/Submit.js


• MyCompany.chart.axis.Numeric est enregistré dans chemin/de/la/source/de/ma/societe/chart/axis/Numeric.js

chemin/de/la/source/ est le répertoire contenant les classes de votre application. Toutes les classes doivent rester à l'intérieure de ce répertoire commun et doit être proprement nommé pour la maintenabilité de votre application.

3) Methodes et Variables

De même que pour les noms de classes, les nom des méthodes et variables ne peuvent contenir uniquement des caractères alphanumériques. Les nombres sont aussi permis mais déconsillé dans la plupart des cas. Ne pas utiliser les underscores, les tirets, ainsi que les autres caractères non alphanumériques.

Le nom des méthodes et variables doivent toujours être sous le format Camel.
Par exemple:

Nom des méthodes accepté:
encodeUsingMd5(),
getHtml() contrairement à getHTML()
getJsonResponse() contrairement à getJSONResponse()
parseXmlContent() contrairement à ofparseXMLContent()

nom des variables accepté:
var isGoodName
var base64Encoder
var xmlReader
var httpServer

4) Propriétés

Les nom des propriétés d'une classe suivent exactement les même conventions que ceux des variables et des méthodes mentionné ci dessus, excepté des cas des constantes statiques. En effet, ces derniers doivent être toutes en majuscule, par exemple:

Ext.MessageBox.YES = "Yes"
Ext.MessageBox.NO = "No"
MyCompany.alien.Math.PI = "4.13"

III. La maîtrise

1. Declaration

1.1) A l'ancienne

Si auparavant vous avez utilisé les versions précédents de Extjs, vous êtes certainement familié avec la fonction Ext.extend pour créer une classe:

var MyWindow = Ext.extend(Object, { ... });

Cette approche est facilement facile à suivre pour créer une nouvelle classe qui hérite d'un autre. Autre que l'héritage direct, nous avions pas eu une API suffisament adaptée pour d'autres aspects de la création de classe tels que la configuration, les satiques les mixins. Nous reverrons tout cela en détail ultérieurement.

Laissez moi vous montrer un autre exemple:

My.cool.Window = Ext.extend(Ext.Window, { ... });

Dans cette exemple, nous voulons un espace nom(My.cool) pour notre nouvelle classe, et qui soit une extension de Ext.window.

In this example we want to namespace our new class, and make it extend from Ext.Window. Il y a là deux problématiques que nous devons traiter:

My.cool a besoin d'exister sous forme d'objet avant de lui assigner l'objet Window. Ext.Window a besoin d'exister/ chargé sur la page avant qu'il soit référencé. La première rpoclématique est résolu avec Ext.namespace, dont l'alias est Ext.ns. Cette méthode transverse récursivement à travers l'arbre de propriété/objet et le créée s'il n'existe pas encore. La partie ennuyeuse est que vous devez retenir les ajouts au dessus de Ext.extend tout le temps.

Ext.ns('My.cool');

My.cool.Window = Ext.extend(Ext.Window, { ... });

La deuxième problématique n'est pas facile à aborder parce Ext.Window peut être dépendant de plusieurs autres classes qui lui est directement/indirectement hérité, qui à son tour ses dépendances peuvent dépendre d'autres classes pour exister. Par cette raison, les application écrites sous les versions précédentes à Ext JS 4.0 devait usuellement inclure toute la librairie sous la forme de ext-all.js même si ils avaient besoin d'une toute petite portion du framework.

1.2) La nouvelle manière

Ext JS 4 a éliminé toutes ces inconvénients avec juste une méthode que vous avez besoin de retenir pour créer votre class: Ext.define. Sa syntaxe basique est défini de la manière suivante:

Ext.define(className, members , onClassCreated );

className: nom de la classe
members est un objet qui représente une collection de la classe membre dans ses paires clé/valeurs.
onClassCreated est une fonction optionnelle de rappel pour être invoquer lorsque toutes les dépendances de cette classe sont prêtes, et que la classe lui-même est pleinement créée. Du fait de sa nouvelle nature asynchrone de la classe de création, cette focntion de rappel peut être utilisé de plusieurs manières. Nous en discuteront dans la section IV.
Example:

Ext.define('My.sample.Person', {

    name: 'Unknown',



    constructor: function(name) {

        if (name) {

            this.name = name;

        }



        return this;

    },



    eat: function(foodType) {

        alert(this.name + " is eating: " + foodType);



        return this;

    }

});



var aaron = Ext.create('My.sample.Person', 'Aaron');

    aaron.eat("Salad"); // alert("Aaron is eating: Salad");

Notons que nous avons créé une nouvelle instance de My.sample.Person utilisant la méthode Ext.create(). Nous devrions utiliser le mot clé new (new My.sample.Person()). Cependant, il est recommandé de toujours prendre l'habitude d'utiliser Ext.create deouis qu'il vous permet d'avoir l'avantage d'avoir un chargement dynamique de classe.

2. La configuration

Sur Ext JS 4.0, nous introduisons une propriété de configuration qui est traité par le préprocesseur puissante Ext.Class avant que la classe ne soit créée. Les caractéristiques comprennent:

Les configuration sont complètements encapsulées depuis les autres classes membres.
Les méthodes getter et setter pour toutes les propriété de configuration sont automatiquement générées à l'intérieur de la classe prototype durant la création de la classe si la classe n'a pas ces méthodes déjà définies.

une méthode apply est ainsi générée pour toute propriété de configuration. Cette méthode setter auto générée appelle la méthode apply en interne avant de modifier une valeur d'une variable. Réécrire la méthode apply pour la propriété de configuration si vous avez besoin de personnaliser un process avant de modifier une variable. Si la méthode apply ne renvoie rien, alors la méthode setter ne modifie pas la valeur. pour exemple, voir, applayTitle en dessous.

Ext.define('My.own.Window', {

   /** @readonly */

    isWindow: true,



    config: {

        title: 'Title Here',



        bottomBar: {

            enabled: true,

            height: 50,

            resizable: false

        }

    },



    constructor: function(config) {

        this.initConfig(config);



        return this;

    },



    applyTitle: function(title) {

        if (!Ext.isString(title) || title.length === 0) {

            alert('Error: Title must be a valid non-empty string');

        }

        else {

            return title;

        }

    },



    applyBottomBar: function(bottomBar) {

        if (bottomBar && bottomBar.enabled) {

            if (!this.bottomBar) {

                return Ext.create('My.own.WindowBottomBar', bottomBar);

            }

            else {

                this.bottomBar.setConfig(bottomBar);

            }

        }

    }

});

Et ici, un exemplede comment il peut être utiliser

var myWindow = Ext.create('My.own.Window', {

    title: 'Hello World',

    bottomBar: {

        height: 60

    }

});



alert(myWindow.getTitle()); // alerts "Hello World"



myWindow.setTitle('Something New');



alert(myWindow.getTitle()); // alerts "Something New"



myWindow.setTitle(null); // alerts "Error: Title must be a valid non-empty string"



myWindow.setBottomBar({ height: 100 }); // Bottom bar's height is changed to 100

3. Les membres statiques

Les memebres statiques peuvent être défini en utilisant la configuration statique.

Ext.define('Computer', {

    statics: {

        instanceCount: 0,

        factory: function(brand) {

            // 'this' in static methods refer to the class itself

            return new this({brand: brand});

        }

    },



    config: {

        brand: null

    },



    constructor: function(config) {

        this.initConfig(config);



        // the 'self' property of an instance refers to its class

        this.self.instanceCount ++;



        return this;

    }

});



var dellComputer = Computer.factory('Dell');

var appleComputer = Computer.factory('Mac');



alert(appleComputer.getBrand()); // using the auto-generated getter to get the value of a config property. Alerts "Mac"



alert(Computer.instanceCount); // Alerts "2"

IV. Gestion d'erreur et débogage

Dans Ext JS 4, certains éléments pratiques peuvent vous aider à déboguer et gérer les erreurs.

Vous pouvez utiliser Ext.getDisplayName() pour afficher le nom d'une méthode. Cela est particulièrement pratique pour gérer les erreurs qui ont une description dans le nommage de classe et de méthode:

throw new Error('['+ Ext.getDisplayName(arguments.callee) +'] un message ici');

Lorsque une erreur est relevée dans une méthode d'une classe définie en utilisant Ext.define(), vous pourrez voir le nom de la méthode et de la classe dans la pile d'appel si vous utilisez les navigateurs qui utilisent le moteur WebKit (Chrome et Safari). Par exemple, voici ce qu'il pourrait être affiché dans Chrome:

Ma première application Extjs 4.0

1. Recommandations

1.1 Navigateur Web

Extjs 4.0 supporte la plupart des navigateurs web connus, de IE 6 à la dernière version de Google Chrome. Nous recommandons cependant durant la période de développement d'application d'utiliser l'un des navigateurs suivant, pour leur outils de debbugging intégré:

• Google Chrome 10+


• Apple Safari 5+


• Mozilla Firefox 4+, avec le plugin Firebug

Ce tutoriel suppose que vous employez la dernière version de Google Chrome. Si vous n'avez pas choisi Chrome, alors prenez un moment pour l'installer et familiarisez vous avec les outils de developpement de Chrome.

1.2 Le serveur Web

Même si il n'est pas obligatoire d'avoir un serveur Web pour faire fonctionner Extjs 4.0, il est hautement recommandé de développez avec un serveur, surtout depuis les restriction des navigateurs du protocole XHR en local. Si vous en avez pas, il est recommandez de télécharger un serveur HTTP Apache et de l'installer

Une fois que vous avez installé ou activé Apache, vous pouvez vérifier qu'il fonctionne avec l'adresse "localhost" dans votre navigateur. Vous devriez voir une page de démarrage indiquant que Apache HTTP Server a été installé avec succès et est en marche.

1.3. Ext JS 4 SDK

Téléchargez la Software Devloppment Kit ExtJs 4.0.Dézippez le fichier dans un nouveau répoertoire 'extjs' à l'intérieure du répertoire root du serveur. Si vous n'etes pas sur de la position de ce répertoire, veuillez consulter la documentation de votre serveur web.

Lorsque vous avez finit d'installer le serveur Apache, naviguez sur "http://localhost/extjs/index.html" de votre navigateur. Si la page de bienvenu de Extjs Js 4.0 apparait, alors vous avez réussit à tout configurer

2. Structure d'une application

2.1 Structure de base

Bien que cela ne soit pas obligatoire, il est préférable de prendre en compte toutes les suggestions listées ci dessous et de les considérées comme des conduites de bonnes pratiques pour la gestion, la maintenance, l'extensibilité et l'organisation de votre application. Il vous est recommandé de reprendre l'organisation structurelle de ExtJs des répertoires dans l'encadré suivant:

- appname    
      - app        
         - namespace            
            - Class1.js             
            - Class2.js            
            - ...    
      - extjs    
      - resources        
         - css         
         - images        
         - ...    
      - app.js    
      - index.html

• appname est un répertoire qui contient tous les fichiers sources de votre application


• app contient toutes vos classes, le style de nommage des classes devrait suivre les conventions listées dans le guide des classes system


• extjs contient les fichiers SDK de Ext JS 4


• resources contient autant les CSS et images additionnels, responsables de l'apparence de l'application, que les autres ressources statiques(XML, JSON, etc...)
• index.html est le point d'entrée du document HTML


• app.js contient toute la logique de votre application

Ne vous focalisez pas sur la création de tous ces répertoires pour le moment, mais focalisons nous sur la production d'un minimum de code pour faire fonctionner une application ExtJs puis de l'executer. Pour cela, nous allons créer une simple application "Hello World" que l'on nommera "Hello Ext". Tout dabors, créons le repertoire suivant et les fichiers dans le repertoire root:

- helloext    
      - app.js    
      - index.html

Alors dézipper la SDK de ExtJs 4.0 dans le repertoire nommé extjs dans le repertoire helloext

Typiquement, une application ExtJs est contenu dans un unique document HTML, index.html. Ouvrez le fichier index.html et insérez le code html suivant:

<html>
   <head>    
      <title>Hello Ext</title>
      <link rel="stylesheet" type="text/css" href="extjs/resources/css/ext-all.css">
      <script type="text/javascript" src="extjs/ext-debug.js"></script>     
      <script type="text/javascript" src="app.js"></ script>
   </head>
   <body></body>
</html>

• extjs/resources/css/ext-all.css contient toutes les feuilles de style pour faire fonctionner le framework


• extjs/ext-debug.js contient le coeur du framework Extjs avec les libraires et les classes


• app.js contiendra le code de votre application

Maintenant, vous etes prêt à écrire votre application. Ouvrez le fichier app.js et insérer le code javascript suivant:

Ext.application({   
   name: 'HelloExt',    
   launch: function() {         
      Ext.create('Ext.container.Viewport', {            
         layout: 'fit',             
         items: [                
         {                    
            title: 'Hello Ext',                     
            html : 'Hello! Welcome to Ext JS.'}            
         ]        
      });    
   }});

Maintenant, ouvrez votre navigateur, et allez à "http://localhost/helloext/index.html". Vous devriez voir un Panel avec une barre de titre contenant le text "Hello Ext" et un message "Welcome" dans le corps du panel.

2.2 Chargement dynamique

Ouvrez l'outil de dev de Chrome et clickez sur la consile. Maintenant rafraichissez l'application Hello Ext. Vous devriez voir une alerte dans la console qui ressemble à cela:

Ext Js 4.0 est livré avec un système de chargement dynamique(que l'on nommera "Loader") permettant de récupérer les ressources javascript uniquement nécessaire pour le lancement de l'application. Dans notre exemple, Ext.create va créer une instance de Ext.container.Viewport. Lorsque Ext.create est appelé, le Loader va tout d'abord checker pour voir si Ext.container.Viewport a été défini. Si il n'est pas défini, alors le Loader va essayer de charger le fichier javascript qui contient le code de la classe Ext.container.Viewport avant d'instancier cet ledit objet. Dans notre exemple, le fichier Viewport.js va être charger avec succès mais le Loader détectera que les fichiers ont été chargées de manière moins optimale. Depuis que l'on a chargé uniquement le fichier viewport.js lorsque une instance de Ext.container.Viewport fut nécessaire, l'éxecution du code a été stoppé jusqu'à que le fichier a été chargé avec succès, provoquant un court retard. Ce retard serait aggravé si nous avions effectué plusieurs appels de Ext.create, parce que l'application attendrait pour chaque fichier à charger, avant de faire la demande de la prochaine requête.

Pour corriger cela, nous pouvons ajouter cette ligne de code avant l'appel de Ext.application

Ext.require('Ext.container.Viewport');

Cela permettra d'assurer que le fichier contenant le code Ext.container.Viewport est chargé avant que l'application ne s'execute. Voius ne devriez plus voir l'avertissement de Ext.Loader Lorsque vous rafraichisserez à nouveau la page.

2.3 Méthodes d'inclusion de la Librairie Extjs

Lorsque vous dezippez ExtJs 4.0, vous verrez les fichiers suivants:

• 1.ext-debug.js - Ce fichier est à utiliser uniquement lors de la phase de développement. Il fournit le minimum des classes Ext Js core pour lui permettre de faire fonctionner normalement le Framework. Toute classe suplémentaire devra être chargé dynamiquement par des fichiers séparé comme il est montré ci dessous.



• 2.ext.js - est identique à ext-debug.js mais minifié pour un usage de production. Cel signifie qu'il faudra l'utiliser en combinaison avec votre fichier d'application app-all.js. (voir section 3)



• 3.ext-all-debug.js - Ce fichier contient toute la librairie ExtJS . Cela peut vous aider à améliorer votre apprentissage, cependant, ext-debug est préféré dans la plupart des cas pour un actuel developpement d'application.



• 4.ext-all.js - C'est une version minifié du fichier ext-all-debug.js qui peut être employé dans un environnement de production. Cependant, il n'est pas recommandé car la plupart des applications n'utilise pas toute les classes qu'elle contient. Il est recommandé que you créez votre propre builder pour votre environnement de production qui sera décrite en section 3.

3. Déploiement

La SDK Sencha nouvellement introduite, rend le déploiement de toute application ExtJs 4.0 plus facile que jamais. Les outils vous permettront de générer un manifeste de toutes les dépendance javascript sous la forme d'un fichier JSB3 (format de ficheir JSBuilder), et créer un builder customizable contenant uniquement le code que votre application a besoin.

Une fois votre SDK installé, ouvrez un explorer et allez à votre répertoire de votre répertoire directement.

cd path/to/web/root/helloext

A partir de là, vous avez simplement besoin de lancer un ensemble de 2 commandes. Le premier génère un fichier JSB3:

sencha create jsb -a index.html -p app.jsb3

Pour les applications construites par des langages dynamiques telles que PHP, Ruby, ASP,..., Vous pouvez cimplement remplacer index.html par l'actuel URL de votre application:

sencha create jsb -a http://localhost/helloext/index.html -p app.jsb3

Cela scanne votre fichier index.html pour tous les framework et fichiers de votre application qui sont actuellement utilisé par votre application, et créée un fichier JSB appelé app.jsb3. Générant le fichier JSB3 pour la première fois, cela nous donne une chance de modifier le fichier app.jsb3 généré avant de le reconstruire. Cela peut vous aidé si vous avez des ressources personnalisée à copier,mais la plupart du temps, nous pouvons procéder à la construction de l'application par la seconde commande:

sencha build -p app.jsb3 -d .

Cela créée 2 fichiers basés sur le fichier jsb3:

1.all-classes.js - Ce fichier contient toutes les classes de votre application. Il n'est pas minifié, ainsi il est souvent utilisé pour débugger votre application construite. Dans ntore exemple, ce fichier est vide parce que notre application "Hello Ext" ne contient aucune classe.

2.app-all.js - Ce fichier est un fichier minifié de votre application avec toutes les classes requises pour le lancer. C'est une version de production du fichier all-classes.js avec app.js.

Une application Ext JS devra avoir une version index.html séparé pour une version de production de votre application. Vous aurez généralement besoin de l'utiliser pour contruire un process ou tester la logique côté serveur, mais pour l'instant, crééez uniquement un nouveau fichier dans le répertoire helloext et appeller index-prod.html:

<html>
   <head>
      <title>Hello Ext</title>
      <link rel="stylesheet" type="text/css" href="extjs/resources/css/ext-all.css">     
      <script type="text/javascript" src="extjs/ext.js"></script>
      <script type="text/javascript" src="app-all.js"></script>
   </head>
   <body></body>
</html>

Noté que ext-debug.jsa été remplacé par ext.js, et app.js a été remplacé par app-all.js. Si vous allez sur http://localhost/helloext/index-prod.html de votre navigateur, vous pourrez voir la version de production de votre application "Hello Ext".

Multi-application sous CodeIgniter

Bonjour à tous,

Un petit tuto pour faire plein d'application ou de site sous le même serveur ...
En général, il suffit de créer plusieurs répertoires, et de faire une simple redirection avec un fichier .htaccess.

Là, c'est à peut près la même chose sauf que l'on utilisera le même framework, CodeIgniter.

Lorsque vous dézipper CI_2.0.0, alors, vous obtenez les fichiers suivants:


Vous ouvrez le fichier index.php, et modifier les 2 valeurs suivantes:

$system_path = "../system";
$application_folder = "../application";

Vous mettez le fichier index.php dans le répertoire application

Enfin dans le htaccess, vous faites pointer dans le répertoire application/index.php !
pour créer une nouvelle application, il suffit de copier/coller le repertoire application, de renommer le repertoire et modifier la variable $application_folder !

Conseils:
- créer un repertoire doc dans la racine ou vous mettez le repertoire user_guide, je vous conseille egalement de mettre toute la doc de php, et des librairie que vous utilisez usuellement (librarie zend, sencha ...)
- dans le repertoire application, je vous conseille de créer un repertoire ressources (ou html), afin de mettre toutes les ressources utilisés dans le site web (image, video, css, ...)
- dans la racine créer un répertoire lib, ou vous mettrez toutes les libs que vous utilisez usuellement (zend, PEAR, ...)
- créer un projet vide, afin de le dupliquer rapidement sans les vues/controlleur... d'un autre projet